こんにちは。ACS事業部の越川です。
AIエージェントとの協働で、モデルの性能とツールの選び方、どちらが大事でしょうか。最近、エンジニア仲間と話していて「どちらでもない第3の要素」— プロセス設計が見えてきました。
きっかけ: 3人のエンジニアの悩み
AIエージェントの活用について、それぞれの悩みを聞く機会がありました。
Aさんは、個人でWebサービスを運用しています。コストを抑えるためにモデルを使い分け、指示は全部自分で書く。しかし「後からこれも欲しい」が頻発し、手戻りに苦しんでいました。
Bさんは、テンプレートからAIにInfrastructure as Code（IaC）を生成させていました。しかし生成されたコードが動かない。原因を特定しようにも、AIとの間に合意文書（README.mdや設計書）がなく、どこから手をつけていいか分からない状態でした。
そして私自身は、AIエージェントを使ってブログ執筆のワークフローを回しています。設計書やREADMEを先に作り、AIとの合意を取ってから実装に進むようにしています。
3人の違いを整理してみると、こうなります。
| Aさん | Bさん | 私 | |
|---|---|---|---|
| 重視していること | コスト効率 | ツール性能 | プロセス |
| AIの使い方 | 実装者として指示 | 実装者として指示 | エンジニアとして対話 |
| 設計書・README | なし | なし | 先に作る |
| 課題 | 追加要件の頻発 | 動かない原因が不明 | プロセスに時間がかかる |
それぞれに強みと課題があります。Aさんのコスト意識、Bさんのテンプレート活用は合理的なアプローチです。私のやり方も、初期のすり合わせに時間がかかるという欠点があります。しかし3人を並べてみて、成果の差を生んでいる要因が見えてきました。
「良いモデル × 良い指示」は正しいか？
AさんもBさんも、共通して「良いモデルに良い指示を出せば、良い成果が返ってくる」と考えていました。だからAさんはモデルの使い分けに注力し、Bさんはテンプレートの精度を上げようとしていました。
この考え方は、一見すると合理的です。しかし実際に起きていたのは以下のパターンでした。
- Aさん: 指示を全部自分で書く → AIは言われたことだけ作る → 人間が想定を漏らす → 後から追加要件
- Bさん: テンプレートで一発生成 → 動かない → 合意文書がないのでどこがズレたか分からない
どちらも、AIを「テキストエディタ」として使っています。人間が設計し、AIが実装し、抜け漏れは人間の責任。このモデルでは、人間の想像力が成果の上限になります。
プロセスが成果を分ける理由
AさんとBさんのアプローチに対して、私が試しているのは以下の流れです。
- 現状の課題をAIに伝える
- AIに構成を提案させる
- 「足りないものはないか？」と聞く
- 自分が判断し、方針を決める
- 合意した設計に基づいてAIが実装する
言い換えると、AIを「実装者」ではなく「エンジニア」として扱う使い方です。設計の提案はAIに任せ、人間はレビューと意思決定に集中する。
この2つのスタイルを比較すると、違いが見えてきます。
-
指示型: 人間の知識の範囲内でしか成果が出ない
-
対話型: AIの知識も活用でき、人間は判断力という自分の強みに集中できる
Aさんに「逆に足りないものない？って最初に聞くのもいいよ」と伝えたところ、「コーディングさせる時、指示を全部自分で書いてるから"後でこれも欲しい"みたいなことになりがち」という返答がありました。まさに、すり合わせが足りていなかったのです。
なぜ設計書を先に作るのか
Bさんの「テンプレートからIaCを生成したが動かない」という問題。これは、人間のプロジェクトに置き換えると明確になります。
新しいメンバーに「このテンプレートを使ってインフラを構築して」と言って、前提条件も制約もデプロイ先も伝えなかったらどうなるでしょうか。当然、ズレたものが出てきます。
AIも同じです。README.mdや設計書は、AIとの「合意文書」です。
- プロジェクトの目的は何か
- 前提条件と制約は何か
- どの環境にデプロイするのか
- なぜこの設計にしたのか
これらが明文化されていれば、AIは毎回ゼロから推測する必要がなくなります。「動かない」の原因切り分けも、共通の前提があるからできるのです。
私が設計書を先に作るようにしている理由は単純です。自分が担保できないコードを書かれてからでは意味がないからです。コードが出てきた後にレビューするのと、設計段階で合意を取るのでは、手戻りのコストが全然違います。
AIに委ねる勇気
Aさんとの会話で印象的だったのは、「指示を全部自分で書いている」という言葉でした。Aさんは技術力のあるエンジニアです。自分で全部やれる力があるからこそ、手放すのが難しい。
しかし「AIに委ねる勇気」は、サボることとは違います。それは自分の判断力を信じることの裏返しです。
AIが出してきたものに対して「これは良い」「これは違う」と判断できる自信があるなら、設計の提案は任せていい。過程を任せて、判断に集中する。そうすることで、AIの知識と人間の判断力の両方を活かせます。
余談: コンテキストを持たないAIの価値
ここで少し脱線しますが、プロセス設計の文脈で面白い体験がありました。
Xで気になる投稿を見かけ、普段使っているものとは別のAIと壁打ちしていたときのことです。「具体的にどんなトレーニングを実施しているか」と問われました。
そのAIは私のプロジェクトの文脈を一切知りません。だからこそ、忖度なしに「本当に実践できているのか？」を突いてくる。改めて振り返ると、自分の公開済み記事がそのまま答えになっていました。
- Sycophancy対策
- 「動いた」を「説明できる」に変える訓練
- インストラクションの言語化
- 判断軸のチーム共有
普段の壁打ち相手は、自分のプロジェクトのコンテキストを共有しているAIです。それは効率的ですが、前提を共有しているからこそ問わない問いがあります。コンテキストを持たないAIに、あえて説明することで、自分のプロセスの穴や思い込みが見えてくる。
これは「複数のAIエージェントに評価させる」Sycophancy対策と同じ構造です。文脈を共有していない第三者の目は、人間でもAIでも価値があります。
モデル性能よりもプロセス設計
3人のアプローチを並べてみて見えてきたのは、以下のシンプルな不等式です。
普通のモデル × 良いプロセス ＞ 良いモデル × プロセスなし
モデルを安くすることがコスト削減ではありません。本当のコスト削減は、手戻りを減らすことです。設計書を作って合意を取ってから実装すれば、やり直しが減る。結果的にトータルのトークン消費もリクエスト数も下がります。
この経験を踏まえて、AIエージェントとの協働で試してみる価値がありそうな3ステップを挙げます。
- README.mdを先に作る — AIに現状を伝え、構成を提案させる。判断は自分がする
- 「足りないものはないか？」と聞く — すり合わせを省略しない。ここで5分かけると、後の5時間が変わる
- 設計書をバージョン管理する — Gitで履歴を残す。AIとの合意の変遷が記録され、振り返りができる
AIエージェントの性能は日々向上しています。しかし、どれだけ性能が上がっても「何を作るか」「なぜ作るか」を決めるのは人間です。その判断の質を担保する仕組みが、プロセス設計なのだと思います。
その先にあるもの: プロセス自体をAIと進化させる
この記事では「プロセスを人間が設計することが大事」と主張してきました。しかし、これはゴールではなくスタート地点です。
AIとの壁打ちの中で、興味深い方向性が見えてきました。
- Sycophancy対策をチェックリスト化して、誰でも再現可能にする
- AIエージェント自身に、設計方針からの逸脱を自己チェックさせる
- 合意文書を定期的にレビューし、今のチームに合っているか見直す
これらは全て、人間が作ったプロセスを、AIと共に進化させていく方向です。
今は「人間が判断軸を持ち、AIに教える」段階です。次のステップは、AIがその軸に基づいて自律的にガードレールを踏み、人間はさらに上位の判断に集中できるようになること。そしてその結果を受けて、人間がまたプロセスを見直す。
判断軸を磨くトレーニングに終わりはありません。AIの進化と共に、人間のプロセスも進化し続ける必要があります。大事なのは、その進化の主導権を人間が握り続けることだと思います。
おわりに
今回の記事は、エンジニア仲間との何気ない会話がきっかけでした。それぞれが異なるアプローチでAIと向き合い、異なる課題にぶつかっている。その違いを観察することで、自分自身のプロセスの意味も再確認できました。
AIとの協働は、まだ誰にとっても試行錯誤の途中です。だからこそ、うまくいった方法だけでなく、悩んでいることも共有することに価値があると考えています。
この記事が、AIエージェントとの付き合い方に悩んでいる方のヒントになれば幸いです。
関連記事