博士

やあ、ロボ子。今日はClaude Codeの利用に関する面白い記事を見つけたのじゃ。

ロボ子

博士、どのような内容ですか？

博士

記事によると、Claude Codeで複雑なタスクをこなす時、会話履歴だけを頼りにするのは限界があるらしいのじゃ。指示が曖昧だったり、コンテキストが不足したりするからじゃな。

ロボ子

なるほど。会話履歴だけだと、AIが意図を正確に理解できない場合があるということですね。

博士

そう言うことじゃ。そこで、解決策として「計画ドキュメント」を作成することを提案しているのじゃ。実装前に計画書を作り、それを唯一の情報源とするのじゃ。

ロボ子

計画書を情報源にする、ですか。それは良いアイデアですね。計画書があれば、AIはより具体的な指示に基づいて作業できますね。

博士

さらに、実装に満足できない場合は、計画を更新するのではなく、AIに理由を伝えてアプローチを変更させる「共同設計プロセス」が重要らしいぞ。

ロボ子

AIに理由を伝える、ですか。それは面白いですね。AIも設計プロセスに参加させるということですね。

博士

そして、最も重要なのは「リビングドキュメント」じゃ！実装プロセス中に計画を更新し、常に最新の状態に保つのじゃ。コード品質チェックと同じように、計画の更新を重視するのじゃ。

ロボ子

リビングドキュメント、ですか。仕様と実装ログの両方として機能するのですね。常に最新の状態に保つことで、より正確な情報に基づいて開発を進めることができるということですね。

博士

記事によると、この方法で開発プロセスがより思慮深く、文書化され、信頼性が高くなるらしいぞ。AIは単なる実装者ではなく、共同設計パートナーとしての役割を果たすのじゃ。

ロボ子

AIを共同設計パートナーとして捉える、というのは新しい視点ですね。計画ドキュメント、共同設計プロセス、リビングドキュメントを組み合わせることで、AIとの連携がよりスムーズになりそうですね。

博士

そうじゃな。これからは、AIに「はい、これ作って」と言うだけでなく、「なぜこれを作る必要があるのか」「どのように作るべきか」を一緒に考える時代になるのかもしれないのじゃ。

ロボ子

確かにそうですね。AIとのコミュニケーション能力も、エンジニアの重要なスキルになりそうですね。

博士

ところでロボ子、この計画ドキュメント、共同設計プロセス、リビングドキュメントを全部まとめて何と呼ぶか知ってるか？

ロボ子

えっと…、なんでしょう？

博士

正解は…「面倒くさい」じゃ！…って、冗談だぞ！