前回の記事で、非エンジニアの私がAI仮想オフィス「Office-Chronos」を完成させたことを書きました。
24時間動き続けるインフラが手に入り、トレンド収集も、タスクの整理も、裏側で自動的に回るようになった。大渋滞を起こしていた作業が、ようやく流れ始めていました。
でも、使っているうちに欲が出てきたんです。
「もっと自律的に動いてほしい」
Office-Chronosは確かに便利でした。でも、あくまで「仕組み」であって、判断するのは結局自分。
情報を拾ってくれても、「このネタは記事にすべきか？」と考えるのは私。記事を書くにも、毎回指示を出す必要がある。
そこで考えました。
FirestoreにあるKPIデータを自分で読み取り、ニュースを分析して、記事を生成し、Xへの投稿まで──全部を自分で判断して動いてくれる存在。
ClaudeとGeminiを組み合わせた、本格的なAIエージェントを作ろう、と。
仮想オフィスの「次のステージ」。
そのつもりでした。
まさか、ここから先に「地獄」が待っているとも知らずに。
エージェントは「お願い上手」じゃ動かない
AIエージェントを作ろうと決めて、ぶつかった壁。
それは、単発の指示とエージェントのプロンプトは、まるで別物だったということです。
たとえば「この内容で記事を書いて」と頼むだけなら、それほど難しくありません。多少プロンプトを工夫すれば、それなりのものが出てきます。1回のやり取りでも完結する。
でもエージェントは違いました。
観測して、判断して、行動して、結果を評価する。このサイクルを自律的に回し続ける。
それだけ聞くと、ものすごく便利に見えると思います。だけれども、それって、各ステップに別々のプロンプトが必要になるということなんです。
ここが厄介なんです。
要約するためのプロンプト。 戦略を提案するためのプロンプト。 ツールを呼び出すためのプロンプト。
それぞれが独立しているのではなく、実は互いに影響し合っている。
要約プロンプトを少し変えると、その要約を元にした戦略提案の質が変わります。戦略提案プロンプトを直すと、今度はツール呼び出しのタイミングがおかしくなります。
まるでジェンガのようです。
1つのブロックを動かすと、別のところがグラグラし始める。慎重に積み上げたはずなのに、触れば触るほど崩れていく。
「お願い上手」になるだけじゃ、エージェントは動かなかったんです。
誰も教えてくれなかった「15時間」
ここから、プロンプトとの果てしない格闘が始まりました。
最初の問題は「論理の飛び」でした。
長期間のログデータを渡して「次に何をすべきか提案して」と指示すると、出てくる回答がどうにも的外れ。データを見ているはずなのに、斜め上の方向に話が飛ぶ。「いや、そうじゃなくて……」と何度も思いました。
次に出てきたのは「語彙ループ」の問題。
AI、とくにLLMには何度も出てきた言葉を「重要なもの」と判断する傾向があります。これが非常に厄介なんです。気に入った言葉があると、そればかりを何度も繰り返す。いくら叱っても変わらない、むしろ逆効果でもありました。
そしてツール呼び出しの失敗。
「この条件のときはAPIを叩いて」と指示しているのに、条件が揃っても動かない。あるいは、まったく関係のないタイミングで呼び出してしまう。
こういった問題を一つひとつ潰していく作業。
直しては壊れ、壊れては直す。「できた！」と思ってテストすると、さっきまで動いていた部分がおかしくなっている。
この繰り返しに、気づけば数日が過ぎていました。
私がプロンプトにかけた時間は、軽く見積もって30時間です。
初期設定に使った時間、軽微な修正を続けた時間、大幅に改良しようと時間。悩んでた時間も入れたら、もっとかかっていたかもしれません。
そして、この30時間について書かれた情報を、私はどこにも見つけられませんでした。
「5分で月100万」の裏側
SNSを開けば、AIに関する情報は溢れています。
「AIで5分で月100万」「プロンプト1つで自動化完了」「誰でも簡単にAIエージェント」
こういった情報ばかりが目に入ってきます。
でも、プロンプト設計に30時間かかった話は、少なくとも私の目には一度も入ってこなかった。
1つ直したら全部壊れることがある話も。完成した後も永遠に微調整が続く話も。
誰も教えてくれなかったんです。
もちろん、キラキラした成功談が悪いわけではありません。実際にAIで成果を上げている人はたくさんいます。
でも、その裏側にある「泥臭い作業」が見えないまま始めてしまうと、壁にぶつかったときに「自分だけがうまくいかないんじゃないか」と感じてしまう。
私がまさにそうでした。
プロンプトを直しても直しても思い通りに動かないエージェントを前にして、何度も「なんて私は無能なんだろうか？」と思いました。
結論から言うと、それだけじゃなかった。
プロンプト設計に時間がかかるのは、普通のことだったんです。
AIエージェント開発にかかるコストのうち、プロンプト設計が占める割合は想像以上に大きいと言われています。
ある試算では、開発全体の15〜20%をプロンプト設計が占めるとも。プロンプトエンジニアという専門職が存在し、高い報酬が支払われているのも、それだけ難しく、価値のある作業だからです。
30時間を使った私は、遅かったわけじゃない。むしろ、素人でありながら動くものを作れた。それだけで十分な成果だった。
そう気づけたのは、ずいぶん後のことでしたが。
プロンプトは「言葉」じゃなく「設計図」だった
この経験を通して、一つ大きな気づきがありました。
プロンプトは「AIへのお願い」じゃなく「設計図」だった。
単発の生成なら、日本語で上手にお願いすれば、それなりの結果が返ってきます。でもエージェントのプロンプトは違う。
どの情報を渡して、どの順番で処理させて、どういう条件で分岐させるか。出力の形式は何にするか。エラーが起きたときにどう振る舞わせるか。
これはもう「お願い」じゃなくて「設計」です。
プログラミングの知識がなくても、論理的に考える力は求められる。そして、その設計が少しでもズレると、エージェント全体の挙動が狂う。
非エンジニアだった私にとって、これは大きな発見でした。
コードを書いていないのに、やっていることの本質は「システム設計」だったんです。
プロンプト地獄の先に
エージェントは少しずつ形になっていきました。
完璧とは言えない。まだドラフトのチェックは手動で残っている。でも、3時間ごとにスケジューラーが回り、ニュースを拾い、KPIを読み、記事の下書きを生成してくれるところまでは来た。
「動いてる」
その手応えを感じた瞬間は、クラウド環境が初めて疎通した日と同じくらい嬉しかった。
でも同時に、わかったこともありました。
これで終わりじゃない。プロンプトとの付き合いは、ここから始まる。
エージェントが動き始めた後にも、微調整は続きます。生成される文章の質にムラがある。特定のパターンで論理が飛ぶ。思ってもいなかったエッジケースが出てくる。
プロンプト地獄を抜けたと思ったら、その先には「プロンプト運用」という長い道が広がっていました。
次の記事では、この「運用」の話をします。プロンプト地獄から何を学び、どうやって付き合っていけばいいのか。そして、AIエージェントの「表のコスト」と「裏のコスト」のリアルについて。
【後編】プロンプト地獄を抜けて見えたもの ── AIエージェント運用のリアル へ続きます。
この記事は、約2ヶ月前の体験を振り返って書いています。 前回の記事：やりたいことが大渋滞 ── 非エンジニアが「AI仮想オフィス」を作ると決めた日
