本記事は、Claude Codeの開発に携わるAnthropicのThariq Shihipar（@trq212）氏がXに投稿した内容をもとに作成しています。原文はこちらをご参照ください → https://x.com/trq212
そもそも「AIエージェント」って何？
Claude Codeの話に入る前に、まず「エージェント」という言葉を整理しておきましょう。
普通のAIチャット（例：ChatGPTやClaude.ai）は、質問に答えるだけです。あなたが何かを聞く→AIが回答する、それで終わりです。
エージェントは違います。 目標を与えると、自分でやるべきことを考えて、ツールを使いながら複数のステップを自律的に実行します。途中で結果を確認して修正することもします。
Claude Codeはそのエージェントの一種で、コードを書いたり、ファイルを操作したり、コマンドを実行したりしながら、プログラミングの作業を自律的に進めます。ただしThariq氏が後で語るように、Claude Codeはもうコーディング専用ではなくなっています。
エージェントに「ツール」を渡すとはどういうことか
エージェントが自律的に動くには「行動する手段」が必要です。その手段のことを「ツール」と呼びます。
- ファイルを読むツール
- コードを実行するツール
- ウェブを検索するツール
- ユーザーに質問するツール
こういったツールをどう設計して渡すかで、エージェントのできることと品質が大きく変わります。この設計こそが、Thariq氏が「芸術」と呼ぶ部分です。
「エージェントの目線に立つ」という考え方
ツール設計で迷ったとき、Thariq氏が使うフレームワークがあります。それは「もし自分がそのAIだったら、このツールで仕事できるか？」という問いを立てることです。
難しい数学の問題を解くとき、どんな道具が欲しいかを考えてみてください。
- 紙とペンだけ：計算はできるが、複雑な問題は厳しい
- 電卓：早くなるが、使いこなせないと宝の持ち腐れ
- コンピュータ：最強だが、コードを書ける能力が前提
重要なのは「道具の性能」ではなく「そのAIが使いこなせる形かどうか」です。Claude Codeにコンピュータを渡すのが有効なのは、コードを書いて実行する能力があるからです。
実例1：AskUserQuestionツールが生まれるまで
「ユーザーに質問する」という一見シンプルな機能でも、完成形にたどり着くまでに3回の試みがありました。この過程はツール設計の本質を教えてくれます。
試み1：既存ツールに質問リストを追加
最初に試みたのは、既存の「計画終了ツール」に質問リストのパラメータを追加することでした。実装は楽でしたが、すぐに問題が出ました。
AIが混乱したのです。「計画を立てる」と「計画について質問する」を同時にこなすのは、考えてみれば矛盾しています。ユーザーの回答が計画と食い違ったらどうすればいいのか。
学んだこと：一つのツールに複数の役割を持たせると、AIが判断に迷う。
試み2：出力フォーマットを変える
次に試みたのは、AIが質問を書き出すテキストのフォーマットを変えることでした。箇条書きで質問と選択肢を書き出させ、それをUIとして解析・表示する方法です。
「だいたい」動きましたが、完璧ではありませんでした。余計な文章が入ったり、選択肢が省略されたり、フォーマットがずれたりすることが頻繁に起きました。
学んだこと：テキスト出力に頼ったルールは脆い。
試み3：専用ツールを作った（採用）
最終的に「AskUserQuestion」という専用ツールを新たに作りました。AIがこのツールを呼び出すと、ユーザーに選択肢付きの質問が表示され、回答が返るまでAIの処理が止まります。
なぜこれが成功したか。技術的な理由もありますが、一番大きかったのは「AIが自然にこのツールを使いたがった」という点です。どんなに優れた設計でも、AIが使い方を理解しなければ意味がありません。
実例2：ToDoリストはなぜTaskシステムになったのか
Claude Codeの初期版には、TodoWriteというToDoリスト管理ツールがありました。AIが「やること」を書き出して、終わったらチェックする仕組みです。
しかし使っていくうちに問題が出てきました。
- AIがToDoを「忘れる」ことがある
- 対策として5ターンごとにリマインドを入れた
- モデルが賢くなったら、リマインドがむしろ邪魔になった
- 「リストを変えてはいけない」という余計な制約をAIが感じ始めた
- 複数の小エージェントが協力する場面で、ToDoリストを共有できない問題も出てきた
そこでTaskツールに置き換えました。ToDoとTaskの違いは明確で、ToDoは「自分が覚えておくもの」、Taskは「チーム全体で進捗を共有するもの」です。
Taskでは複数のエージェントが同じタスクを見て、状況に応じて変更・削除もできます。
ここで学んだ最も重要なこと：AIモデルが進化するにつれて、以前は「必要だった制約」が「足かせ」になることがある。過去の前提を定期的に疑い直すことが不可欠です。
実例3：コードベースの検索機能の進化
Claude Codeが「プロジェクトを理解する」ための仕組みも、この1年で大きく変わりました。
最初：RAG（検索拡張生成）を使った
RAGとは、大量の文書をあらかじめ処理・インデックス化しておき、質問に関連する部分だけを取り出す技術です。速くて強力でしたが、セットアップが必要で環境によって不安定でした。そして何より、AIが「情報を与えられる」受け身の存在でした。
次：GrepツールでAI自身が検索
「ウェブ検索できるなら、コードも検索できるはず」という発想で、Grep（テキスト検索）ツールを渡しました。するとAIが自分でファイルを探して文脈を作れるようになりました。
現在：スキルを使った「段階的開示」
スキル機能の登場で、さらに洗練された形になりました。
AIがスキルのファイルを読む→そこで別のファイルが参照されている→そのファイルも読む→さらに深く参照を辿る……という、必要な情報を「探す旅」を自律的にこなせるようになりました。この考え方を「段階的開示（Progressive Disclosure）」と呼びます。
1年前はコンテキストをほぼ自分で作れなかったのが、今では複数階層のファイルを自在に辿って必要な情報を正確に見つけられます。
段階的開示の具体例：Claude Codeガイドエージェント
「Claude Codeの使い方をClaude Code自身に聞いても答えられない」という問題がありました（「MCPの追加方法は？」「スラッシュコマンドとは？」といった質問です）。
解決策の候補は2つありました。
- システムプロンプト（AIへの初期指示）に全情報を入れる → コンテキストが膨らみすぎて本来の仕事の邪魔になる
- ドキュメントへのリンクを渡す → 大量の情報を読み込みすぎる問題が起きた
最終的に採用したのは「Claude Codeについての質問が来たとき専用のガイドサブエージェントを起動する」という方法です。このサブエージェントはドキュメントを効率的に検索する専門家として設計されており、新しいツールを追加せずに機能を拡張できました。
ツール設計には「決まった正解」がない
ここまでの事例を見ると、「じゃあ正しいツール設計の方法を教えて」と思いますよね。でもThariq氏は明確にこう言っています。「ツール設計は科学ではなく芸術だ。模範解答は存在しない。」
最適な設計は、使っているモデルの特性、エージェントの目的、動作環境によって変わります。
ただし、どんな状況でも使える指針はあります。
- ツールの数は少なく保つ。 選択肢が増えるほどAIは迷う。新しいツールを追加するハードルは高くすること
- AIが自然に使える形かどうかを確認する。 高性能なツールより、AIが使いたがるツールを優先する
- AIの出力を読み続ける。 失敗パターンを観察して、何が足りないかを把握する
- 過去の前提を定期的に見直す。 モデルが進化したら、古い設計が逆効果になっていないか確認する
「エージェントのように考える」 — これがツール設計を磨き続けるための唯一の方法です。
コメント