結論
- AIエージェントは事前設計が無意味になる領域に入ってる
- 「まず動かす、設計はあとから収束する」が、現時点で僕が見つけた一番マシな順序
- 非エンジニアがAIで作るプロジェクトほど、この順序を守ったほうが早く着く
以下は、そう思うに至った半年分の話。
設計図を描くのが好きだった頃
半年前、僕はAIエージェントを作るときに「まずアーキテクチャ図を描く」派だった。
きれいなレイヤー分け、責務の分離、再利用可能なモジュール構造。役割ごとにエージェントを切って、入出力のスキーマを決めて、依存関係を有向グラフで整理する。Figma で図を描いてから実装に入る。全部、紙の上では美しかった。
でも実装すると毎回壊れた。
理由は単純で、AIエージェントの挙動は事前に予測できないからだ。プロンプトを変えれば応答が変わる。MCPを足せば依存関係が動的に変わる。LLM のバージョンが上がれば、昨日通っていたフローが今日は別のパスを取る。設計図は実装より早く陳腐化する。
しかも厄介なのは、図を描いた時点で「この通りに動くはずだ」という思い込みが脳に焼きつくこと。実装で壊れたとき、設計を疑わずに「実装が悪い」と判断してしまう。図に縛られてバグの本当の場所を見落とす。
失敗例：きれいに設計した自律エージェントが、動かなかった
一番痛かった失敗を書いておく。
ある自律マネタイズシステムを設計したことがある。匿名化して書くと、複数のコンテンツチャネル（note、Zenn、Medium、X）を横断して毎日記事を出すエージェント群を、1人で運用するというものだ。
最初の設計はこう描いた：
- topic_curator：毎朝トピック候補を集める
- drafter：ドラフトを書く
- reviewer：自己レビューして直す
- publisher：各プラットフォームに投稿する
- analytics：反応を回収して次のキュレーションに渡す
矢印で繋いで、入出力をJSONで定義して、責務を分けた。完璧な「マイクロサービスっぽい」構成。
実装してみたら、最初の3日で破綻した。
-
topic_curatorが出すトピックの粒度が、drafterの想定と毎回ズレる -
reviewerが「全部直すべき」と判断して無限ループに入る -
publisherがプラットフォームごとに違う認証フローを要求し始めて、結局この層が一番厚くなる -
analyticsは数日PV溜まらないと意味のあるシグナルを返さないので、フィードバックループが回らない
責務を分けたつもりが、実態の境界が設計図と一致していなかった。直そうとすると、設計図ごと描き直しになる。けど描き直してもまた壊れる。
やり方を変えた
詰まって、いったん全部捨てた。残したのは1個だけ。「毎日1本、何かを出す」というゴールだけ。
そしてエージェントを設計せず、ノートブックでベタ書きのスクリプトを1本書いた。トピック決め打ち、ドラフトはそのまま LLM に投げる、レビューなし、投稿先1つ。300行くらい。汚い。
これを毎日走らせた。動いた。出た。
そこから初めて、汚いスクリプトを観察して「この部分は毎回同じことをやっているから関数に切れる」「ここは LLM に毎回判断させてるから、プロンプトに切り出すべき」と、事後的に構造を抽出していった。
3週間後に出来上がった構造は、最初に図で描いたものと驚くほど似ていた。でも全然違うものになっていた。 名前は同じでも、責務の切れ目が違う。reviewer は無くなって editor（部分書き換えだけする軽量エージェント）になった。analytics は別プロセスに切り離した、ループの中じゃなくて。
結局、図は同じに見えても、実装が定義した境界と 想像が定義した境界は別物だった。
「設計はあとから収束する」とはどういう意味か
これは「設計するな」って話じゃない。むしろ逆で、設計は実装の後に正しく書けるという話。
事前に描く設計図は仮説でしかない。AIエージェントは未知の挙動を内包するから、仮説の精度が低い。低い精度の仮説に従って実装すると、実装も低精度のものができる。
ところが、まず動くものを作ると、そこから観測される実際の挙動を元に設計を組める。これは精度が高い。観測ベースだから。
順序が逆なだけで、設計を捨てているわけじゃない。
非エンジニアにこそ効く
この順序、エンジニアより非エンジニアの方が活きると僕は思っている。
非エンジニアは経験上、最初から「正しい設計」を描く能力を持っていない（だってエンジニアじゃないから）。なのに、AI使う系の本やコンテンツは「まず要件定義」「まずアーキ図」と言ってくる。これに従うと、描けない図を描こうとして詰む。
逆に「まず動かす」順序なら、最初に必要なのは「最小の動くもの」だけ。1個のプロンプト、1個のスクリプト、1個の出力。これなら非エンジニアでも作れる。動かして観察する能力は、エンジニア経験と関係ない。むしろ非エンジニアの方が先入観なく観察できる場合がある。
僕の周りで「AIで何か作りたいけど何から手を付けたらいいか分からない」と言う人は、たいてい設計から始めようとして止まってる。一行のプロンプトから始めれば、3日で何か動く。
それでも設計を先にする場面
例外もある。他人と協業する場面だ。
1人で動かしている限り「実装→観察→設計」の順でいい。けど他人と作るときは、共通理解のためにある程度の事前設計図が要る。完璧な図じゃなくていい、「ここで何を作る、入出力はだいたいこう」程度のスケッチで十分。
このスケッチも、ベテランエンジニアの図とは別物だ。仮の合意であって、確定の仕様ではない。動かしたら変わる前提で描く。図が変わったら「設計通りに動かなかった」じゃなくて「設計が現実に追いついた」と捉える。
学び
「動かしてから考える」は雑に聞こえるけど、実際は規律のある順序だ。手抜きじゃない。何を観察するか、いつ設計に転じるか、どこで止めるかを毎日判断し続けないと回らない。
ただ、この順序を採用してから、僕が壊すコードの量は減った。書く設計図の量も減った。出力は増えた。
たぶんこれは AI ネイティブ時代の正しい順序の一つで、僕がいま見えてる範囲ではこれが最善。1年後にはまた違うことを書いてるかもしれない。それでいい。まず動かす、設計はあとから収束する。
次回予告
次は「動かしながら設計を収束させるための観察ノートの取り方」を書こうと思っている。Notion でも Obsidian でもいいんだけど、エージェントの挙動を観察するための日次ログをどう構造化してるか。地味だけど、これがないと「動かしてから考える」は「動かしたまま考えない」に堕落する。
— Sai
この記事が役に立ったら：僕が自律エージェントを動かすときに実際に使っているプロンプトを2つのパックにまとめました — 自律エージェント用プロンプト100選 と Claude Code パワーユーザー向けプロンプト。どれも「まず動かす」発想で、ターミナルに貼って即使えます。
Top comments (0)