AIエージェントを「動かす」のは簡単だ。「思い通りに動かす」のは別の話だ。

「社員ゼロで複数サービスを同時運営」「AIエージェントで専門チームを構築」——そういうニュースを見かけるようになった。

経営者こそClaudeCodeを使うべきだ、CLAUDE.mdを書けばエージェントが動く、AIで専門チームを作ろう——その主張は正しい。私も同じことをやっている。

ただ正直に言う。「動く」と「思い通りに動く」は、まったく別のことだ。

そしてこれは他人への批判ではなく、自分への戒めでもある。

私が半日かけてやったこと

先日、開発プランナーエージェントを設計した。複数プロジェクトを横断して「今日何をやるか」を提案し、セッション終了後のログを受け取って進捗を更新する——そういう役割のエージェントだ。

ただ、作り始める前にまず1時間、そもそも作る意味があるのかを検討した。ManusやOpenClawのような汎用エージェントツールがすでにある。「誰でも簡単にエージェントを動かせる」という文脈で流行っているものだ。それで済むなら自作する必要はない。

調べた結果、汎用ツールで出てくるものの大多数は「それCoworkでいいんじゃない？」というものだった。私がやろうとしているのは、エージェントを「動かすこと」ではなく、自分の開発フローと判断基準を持った固有の役割を編制することだ。汎用ツールでは代替できないと判断して、自作することにした。

次の1時間は、一般的にこの種のエージェントに何が求められているかの洗い出しに使った。そこから2時間、他の人の実装を見た。参考になるかと思ったが、前提が違いすぎた。結果、自分で設計した。

できあがったファイル群の規模を、後から数えてみた。

ファイル	行数	文字数
エージェント定義（CLAUDE.md）	116行	2,821文字
設計判断・学びのログ（insights.md）	149行	6,283文字
タスク・残債（current-debt.md）	172行	7,782文字
ロードマップ（roadmap.md）	94行	2,015文字
リポジトリ全体定義（CLAUDE.md）	20行	238文字
合計	551行	19,139文字

エージェントへの命令は116行だ。だがその周辺に、約2万文字の思考が積み上がっている。

「動かす」指示より、「思い通りに動かすための設計判断」の方が、はるかに多い。

なぜそうなるのか

エージェントの設計は、要件定義と同じ構造をしている。

「わかる人に任せれば作ってくれる」は本当だ。だが、自分が何を作りたいかを言語化できていなければ、わかる人に頼んでも思ったものは出てこない。エージェントも同じだ。

「完了かどうかの判断はしない。ログの記載をそのまま反映する」——これを書かなければ、エージェントは自己判断で完了扱いにする。「不明な場合はNAと記入する、仮の数字は入れない」——これを書かなければ、適当な数字を入れてくる。「解除確認は別エージェントが担当。プランナーは保留のまま追跡しない」——責務の境界を明示しなければ、越えてくる。

穴があれば、穴の通りに動く。それだけだ。

整理されていない要求をAIに渡しても、整理されていない結果が返ってくるだけだ。これはAIの問題ではなく、要求を言語化できていない人間側の問題だ。

「任せる」の前に必要なこと

私はコードは書かない。AIを指揮して、設計と判断に集中するスタイルをとっている。

だからこそ言える。AIに任せるほど、自分の思考の解像度が問われる。

「何をやりたいか」だけでなく、「何をやらせないか」「判断が割れたときどうするか」「完了の定義は何か」——これらを自分の中で整理できていないと、エージェントは動くが思い通りには動かない。

数行のCLAUDE.mdで動くのは本当だ。ただしそれは、自分の要求が整理されていることが前提だ。

「AIエージェントのみで複数サービス同時運営」は嘘ではないかもしれない。ただ、動いているサービスの数と、思い通りに動いているサービスの数は別の話だ。私自身も含めて。

AIを指揮するとはどういうことか

結局のところ、AIエージェントの設計は、自分の思考を構造化する作業だ。

「どう動いてほしいか」を言語化し、「どう動かれると困るか」を明示し、「判断できない場合はどうするか」を決める。これは経営判断と同じ構造をしている。

AIが賢くなるほど、人間側に求められるのは技術ではなく、思考の精度だ。

エージェントに半日かけたのは、技術的な理由ではない。自分が何を作りたいかを、正確に言語化するのに時間がかかったからだ。

そして、投資対効果の話をしよう

AIエージェントの記事には、たいてい「便利だった」しか書いていない。だから正直に書く。

今回の開発工数を上回るメリットが出たかと問われれば、現状まだ出ていない。

ただ一つ気づいたことがある。insights.mdやcurrent-debt.mdに積み上がった約2万文字は、エージェントを設計した副産物だ。エージェントと対話しながら設計判断を言語化していく過程で、自分自身のプロジェクトへの理解が構造化されていった。これは工数換算できない資産だ。

エージェントが便利だったという話ではなく、エージェントを設計する行為そのものが、自分の思考を整理する装置として機能した——そういう側面がある。

とはいえ、エージェントはメンテナンスも必要になる。ルールの追加、例外処理の整備、運用フローの変化への追従——作って終わりではない。有形の投資対効果という意味では、使い続けながら判断するしかない。現状は便利だし今は使う価値がある。ただ将来も使えるかどうかは、要件の変化次第だ。

「AIエージェントを導入した」は出発点であって、ゴールではない。

おまけ：このブログを書く前にAIエージェントにブログを書かせてみた。

この記事を書くにあたって、AIエージェントにブログを書かせたらどうなるんだろうという興味から指示をしてみた。指示はシンプルに「テーマはAIエージェントを設計した話をしようと思うから、ブログ用に情報をピックアップしてまとめて」だけだ。

指示しなくても、設計判断の核心を自力で抽出し、4軸に整理し、ブログの骨格まで作ってきた。その出力は別記事としてそのまま公開している。→AI記事：開発プランナーエージェント設計記録ブログ

「エージェントについての記事を、エージェントが整理する」という入れ子構造になっている。これがAIを指揮するということの、現時点での一つの私の回答で、やってみて自分自身で面白いなと感じた。

ただし繰り返すが——これができたのは、insights.mdに設計判断が積み上がっていたからだ。エージェントが賢いのではなく、賢く動けるだけの思考の蓄積があったからだ。