仕組みを作るなら、時間をかけてしっかり作り込みたくなります。手順を細かく決め、役割を分け、例外にも備える。人が使う業務の仕組みなら、それは正しい作り方です。
ところが、AIに作業を任せる仕組みは事情が違います。私たちは、開発作業をAIに任せるためのワークフロー（作業の流れ）を、合わせて7日ほどで組み立てました。その前提だった「役割ごとにモデルを使い分けて費用を抑える」という考え方は、モデルの世代が進んだことで、ほとんど意味を失いました。
では、すぐ古くなるものを、どう作ればよいのか。私たちの答えは、組織に残すものと、使い捨てる前提のものを分け、後者は最小限の定義で素早く作って業務に使う、というものです。この記事では、実際に作ったものと手順、その扱い方を紹介します。作り方の巧拙を見せたいのではありません。すぐ古くなることを前提にした取り扱い方を、共有したいと考えています。
前提：ワークフローを作る道具は、二つだけ
使った道具は二つです。
- サブエージェント：設計、実装、レビューといった特定の役割だけを担うAIです。全体を取りまとめるAIから、仕事を割り振られます。
- スキル：作業の進め方を、AIへの指示としてまとめたものです。どの順で進め、どのサブエージェントに何を任せるかを書きます。
この二つを組み合わせて、繰り返し行う開発作業を、決まった流れでAIに任せられるようにしました。作る途中で起きた失敗は、「目的だけ渡したら、AIが頼んでいない仕様を育て始めた」で紹介しています。この記事では、その失敗の外側、つまり何をどの順で作り、どう扱うつもりだったかを書きます。
実用化しやすい作業から、順に作った
対象にしたのは、繰り返し行う五つの開発作業です。比較的すぐ実用化できそうな障害の原因調査から始め、次の順に作りました。
| 順番 | 作業 | 作るのにかかった日数 |
|---|---|---|
| 1 | 障害の原因調査 | 1日 |
| 2 | 単純な障害の改修 | 1日 |
| 3 | 大規模な改修に向けた設計書の作成 | 1日 |
| 4 | 設計書に基づく大規模な改修と、ユニットテストによる検証 | 2日 |
| 5 | E2E（画面の操作から外部との連携まで、業務の流れを通して確かめるテスト）での回帰テスト | 2日 |
一つの作業にかけたのは、1〜2日です。作り込むより、必要最低限の定義で素早く作り、業務に使うことを想定していたからです。以前の記事で紹介した、AIが頼んでいない検査を足し続け、気づくまで丸1日かかった件も、この期間の中で起きています。
定義は二つに分けた：役割はサブエージェントに、使い方はスキルに
定義では、何をどこに書くかを分けています。この分け方は、最初から私たちが決めていたものではありません。はじめは人が指定した別の分け方で実装しましたが、うまく回りませんでした。安いモデルに難しい作業を渡しすぎていたようです。組み合わせの問題だったのかもしれませんが、安いモデルへの期待を大きくとりすぎていました。そこでAIに再設計させて出てきたのが、次の分業です。この分け方にしてから試行錯誤がしやすくなったようで、ほかの要因もあるかもしれませんが、作って試して直す回転が良くなりました。
サブエージェントの定義は、役割、目論見（何のためにいるか）、使うモデルの指定だけにしました。そのサブエージェントをどの場面で呼び、何を渡し、結果をどう扱うかは、すべてスキルの側に書きます。説明のために単純化すると、次のような分け方です。
# サブエージェント：設計レビュー役（説明用に単純化した例）
役割：設計書を読み、要件との食い違いと抜けを指摘する
目論見：実装に入る前に、設計の誤りを見つける
モデル：（ここで指定する）
# スキル：大規模な改修（説明用に単純化した例）
1. 設計書を作成役に渡し、設計書を作らせる
2. 設計書を設計レビュー役に渡し、指摘を受ける
3. 指摘を反映した設計書をもとに、実装役に改修させる
4. ユニットテストを実行し、結果を報告する
5. レビューと修正の往復は3回まで。超えたら人に判断を戻す
こう分けたのは、モデルの切り替えを一か所で済ませるためです。新しいモデルが出たら、役割ごとのモデルの指定を書き換えるだけで、スキルの手順には手を入れずに試せます。すぐ古くなることを前提にするなら、古くなりやすい部分を一か所に集めておくのが、いちばん安い備えだと考えました。
スキルの中身も、性質の違う二つに分けて見ています。作業の順序や、何を満たせば完了とするか（たとえば、テストをすべて通すこと、往復の回数に上限を置くこと）は、モデルが変わっても残ります。一方、それぞれの手順をどの役割のサブエージェントに任せるかは、使い捨てる側です。
作り方：定義はAIに書かせ、試験とレビューも任せた
定義そのものも、人が一から書いたわけではありません。ワークフローごとに、次の手順で作りました。
- 目的をAIに示す。たとえば「障害の報告を受けて、原因の候補とその根拠を示せるようにする」といった形です（説明用の例です）。
- その目的から、スキルとサブエージェントの定義をAIに書かせる。
- 作ったワークフローを動かし、挙動を試験させる。題材には、実際の過去の障害や改修を使いました。
- 試験の結果を、別のAIに独立してレビューさせ、指摘に沿って定義を直させる。試験の合否の判断も、指摘への対応も、AIに任せました。
人がしたのは、目的を示すことと、最後に結果を確かめることです（逸脱に気づいて立て直したときを除きます）。なお、AIに任せた試験とレビューは、ワークフロー自体が動くかどうかの確認です。ワークフローを使って作った実務の成果物は、人のレビューや回帰テストで最終的な品質を確かめる前提です。
振り返って、人が持つべきだったこと
ただ、これが適切な進め方だったかどうかは、正直なところ分かりません。以前の記事で紹介した逸脱は、3と4の、試験とレビューと修正（以前の記事でいう実装とレビューの往復）を繰り返す中で起きました。AIが頼んでいない検査を足し続け、往復が止まらなくなったのです。
いま振り返ると、次の二つは、人の側で決めて渡すべきだったと考えています。
- 完成の基準。どの題材で、何ができれば「動いた」とするか。試験もレビューもAIに任せると、完成の基準までAIが決めることになります。基準が少しずつ引き上げられても、止める人がいません。
- やらないことと、終わりの条件。目的と一緒に、範囲外とすることと、往復の回数の上限を渡します。実際、立て直しでは、親エージェントに完成の基準と往復の回数の上限を渡し（進行管理の変更と同時でした）、最後まで処理できるようになりました。
初めて作るなら、AIに定義を書かせる進め方は、試してみる価値があると思います。そのときは、この二つだけは人が先に書いて渡してください。
陳腐化は、モデルの世代交代で一気に来た
分業の仕組みを作った当初の狙いは、費用でした。AIのモデルは、同じ量の入出力あたりの料金に大きな差があります。そこで、実装には安いモデルを、設計とレビューには判断能力を重視したモデルを置き、安いコストで作業をこなす分業を考えていました。
ところが、その後のモデルの世代交代で、性能の高いモデルが一段と優秀になりました。いまの私たちの作業では、細かく分けるより、大まかに任せたほうが、完了までの時間が短くなります。以前の記事「目的だけ渡したら、AIが頼んでいない仕様を育て始めた」を書いた時点では「性能の高いモデル一つに任せたほうが早いのではないか」という仮説でしたが、その後、実際にそう使うようになりました。単価は高くても、完了までにかかる料金の合計は、かえって安くなることもあります。さらに、エージェント同士のやり取りを通して生じていた認識の食い違いも減ります。前のAIの推測が、次のAIに確定した仕様として受け継がれる問題は、「AIは書かれたことしか見ていない」で紹介したとおりです。
分業そのものは、それなりに回っていました。大まかに任せるようになったのは、主にモデルの進化によるもので、以前の記事で書いた往復の暴走が理由ではありません。あの暴走は、構築の途中、完成の基準と往復の上限をまだ渡していなかった段階で起きたことです。
いまは、組織への展開は止めたまま、一部の開発者が、分業を簡略化した形で使っています。モデルの指定を一か所にまとめた備えは、モデルを試すためのものでした。今回古くなったのは、モデルの指定ではなく、費用を抑えるために役割を細かく分けるという構成そのものです。費用のための分業は、その前提が崩れれば、それだけで役目を終えます。
すぐ古くなる前提での、私たちの考え方
この経験から、AIに作業を任せる仕組みについて、私たちは次のように考えています。
- 組織に残すものと、使い捨てるものを分ける。残すのは、作業の手順と品質の基準です。どのモデルを使うかだけでなく、どの役割に分けて組み合わせるかという構成も、使い捨てる前提で扱います。
- 古くなる場所を決め打ちしない。私たちは、古くなるのはモデルの指定だと考えて一か所に集めました。実際に古くなったのは、役割を細かく分けるという構成のほうでした。交換できる場所を用意するだけでは足りない、と考えています。
- 一つの作業を、短い日数で使える形にする。私たちの場合は1〜2日でした。作り込みに時間をかけるほど、古くなったときに捨てにくくなると考えています。
- 完成の基準、やらないこと、終わりの条件は、人が書く。定義をAIに書かせても、何ができれば完成で、何をしないで、どこで止めるかは人が決めます。最小限の定義でも、ここは省きません。
- モデルが変わったら、仕組みの前提から見直す。手順を直す前に、そもそも分業が必要な理由が残っているかを確かめます。
まとめ：作り込むより、作り直せるように作る
AIのモデルは、次々に新しい世代が出ます。その上に載せる仕組みは、どれだけ丁寧に作っても、前提ごと古くなることがあります。私たちが分業のために組み立てたワークフローも、モデルの世代交代で、その前提を失いました。
だからこそ、作り込むより、作り直せるように作る。残すべき手順と品質の基準は組織の資産として持ち、実行の仕組みは最小限の定義で素早く作って、すぐ業務に使う。新しいモデルが出たら、ためらわずに作り直す。これが、すぐ古くなる道具と付き合うための、私たちの取り扱い方です。