AIエージェントの開発｜作るのはコードより「任せ方」── 7つの部品・5つの段階・自社で作るか頼むかの分かれ目

AI エージェントを作りたい。自社で組むにせよ、社内の誰かに組ませるにせよ、開発会社に頼むにせよ、最初に突き当たるのは同じ問いです。何を作れば「開発した」ことになるのか。調べると、モデルの選び方、フレームワークの比較、ツールの使い方が並びます。どれも間違いではありませんが、それらを揃えたところで、任せられるエージェントは出来上がりません。私たちは自社の日常業務を、自分たちで開発した AI エージェント群で回しています。その経験から先に結論を書くと、AI エージェントの開発とは、任せる仕事を言葉にし、任せられる状態にするための部品を組み、動かして直すことです。モデルを選ぶこともコードを書くことも、その一部でしかありません。開発の工数の大半は業務の言語化にあり、そこは技術者ではなく、業務を知る人が担う仕事です。だから自社で作っても開発会社に頼んでも、自社が持つ仕事は消えません。この記事では、開発とは何をすることかを人向けのシステム開発との違いから押さえ、エージェントを構成する 7 つの部品、設計 1 枚から本番までの 5 つの段階、自社で毎日回している開発の型、自社で作るか頼むかの分かれ目、つまずきやすい 3 つの型までを、これから最初の 1 体を作る方が順番どおりに進められる形で整理します。

AIエージェントの開発とは ── モデルを選ぶことでも、コードを書くことでもない

言葉の整理から始めます。AI エージェントとは、目的を渡すと必要な手順を自分で組み立てて実行し、結果まで進める AI のことです。仕組みとしては、考える頭脳(AI モデル)、触れる道具、覚えておく記憶、そして何をどう進めるかを書いた手順書、の 4 つの部品でできています(部品の役割と「計画・実行・確認」のループは「AIエージェントとは」に 1 本にまとめています)。では、その AI エージェントを「開発する」とは、何をすることでしょうか。検索で並ぶのは、フレームワークの比較、開発ツールの使い方、入門書、開発会社の一覧です。作る側の情報と頼む側の情報が混ざっていて、しかも作る側の情報は「頭脳と道具をどうつなぐか」に偏っています。それは開発の一部ではあるものの、開発の工数の中では小さい部分です。私たちが自社の業務用にエージェントを組んできた実感で、工数の大きい順に並べると、業務の言語化(何を・どこまで・どんな判断基準で任せるかを文章にする)、道具の接続と権限の設計、合格の例を作って試す作業、そして最後にコードやプロンプトの記述、という順になります。

なぜ順番がこうなるのか。AI エージェントの開発が、人向けのシステム開発と違う点が 3 つあるからです。

仕様が「機能」ではなく「手順と判断基準」であること。これが、開発の主役を技術者から業務を知る人へ移します。ボタンの挙動は技術者が決められますが、「この問い合わせは返信してよいか、止めるべきか」の判断基準は、その業務をやってきた人にしか書けません。そして正しさが確率的であること。これが、開発に「合格の判定」と「止まる場所」という、人向けの開発にはない部品を要求します。テストが通れば安心、という前提が置けないので、外れたときに事故にならない構造を先に作るのです。最後に、完成の定義が「動いた日 = 初日」であること。これが、開発を一度きりの工事ではなく、続く仕事にします。この 3 つの違いを押さえておくと、次に挙げる 7 つの部品のうち、なぜ後半の 3 つが要るのかが自然に分かります。

AIエージェントを構成する 7 つの部品 ── 4 つは仕組み、3 つは「任せる」ための部品

AI エージェントを開発するとき、揃える部品は 7 つです。前半の 4 つは、先ほどの定義に出てきた「仕組み」の部品で、これがあればエージェントは動きます。後半の 3 つは「任せる」ための部品で、これが無いとエージェントは動くけれど任せられない、という状態になります。

• ①頭脳(AI モデル) ── 考える主体です。どのモデルを使うかは開発の話題の中心になりがちですが、業務用のエージェントでは「賢いほど良い」とは限りません。文章の質が価値を決める仕事には上位のモデルを、突き合わせや分類のような仕事には軽いモデルを、と仕事ごとに割り当てるのが実務です。モデルは差し替えが利く部品でもあります。
• ②道具 ── エージェントが触れる先です。ファイルを読む、社内の記録を検索する、外部のサービスを呼ぶ、書き出す。道具が多いほど仕事の幅は広がりますが、接続 1 本ごとに設計と点検が増えます。最初の 1 体は道具を 1〜2 つに絞ります。
• ③記憶 ── 何を覚え、何を覚えないかです。会話の中で一時的に覚えるもの、業務の判断軸として長く持つもの、そして「人の本文や個人の情報は保持しない」という覚えない側の決めごと。記憶の設計は、後述の権限とセットで考えます。
• ④手順書 ── 役割、手順、判断基準、禁止事項、出力の形を文章にしたものです。エージェントの品質は、頭脳よりも手順書で決まります。書き方の 5 つの構成要素は「AIに渡す手順書の書き方」にまとめています。
• ⑤権限 ── どこを読め、どこに書け、何を動かせるかを、手順書の外側で物理的に決めるものです。「やってはいけない」を手順書に書いても柵にはなりません。読む・書く・動かすの 3 層で権限を作る方法は「AIエージェントのセキュリティ」に書きました。
• ⑥止まる場所 ── お金が動く、外に送る、人に関わる、本番に反映する。取り返しのつかない操作の手前で、エージェントが必ず人の確認を待つ場所です。止まる場所が設計されていると、そこまでは安心して任せられます。
• ⑦合格の判定 ── 何をもって「できた」とするかです。手順書を変えるたびに通す合格・不合格の例と、本番で人が確認する観点。判定が無い開発は、良くなったのか悪くなったのかを誰も言えません。

開発の現場で最初に起きるのは、①と②を盛ることです。より賢いモデル、より多くの道具。動くものが早くできるので、手応えがある。ところが⑤⑥⑦を後回しにしたエージェントは、動いた瞬間から「これに何を任せてよいのか分からない」という状態に入ります。読める範囲が広すぎて社内の誰も権限を把握しておらず、止まる場所が無いので外に出る仕事は任せられず、合格の判定が無いので手順書を直しても良くなったか分からない。「任せる」ための 3 部品は、賢くするための部品ではなく、任せる範囲を広げるための部品です。開発の順番を決めるときは、この 3 つを後半に置かず、手順書と同時に組みます。

AIエージェント開発の 5 つの段階 ── 設計 1 枚から本番まで

部品が分かったら、組む順番です。AI エージェントの開発は 5 つの段階で進めます。段階の数そのものより、段階 2 を飛ばさないことが要点です。

段階 1 ── 業務を 1 つ選び、工程に分解する

最初の 1 体は、1 つの業務に絞ります。選び方の基準(毎回ほぼ同じ手順で、やり方を言葉で説明でき、失敗しても取り返しがつく)は「AIエージェント導入の進め方」に書いたとおりです。選んだら、その業務を工程に分けます。受け取る・調べる・作る・確認する・送る、のように分解すると、どの工程を任せてどの工程を人が持つかの線が引けます。分解の仕方は「AIエージェントは業務のどこに入るのか」で扱いました。開発の観点で付け加えるなら、分解した工程のうち「作る」だけを最初に任せ、「送る」は人が持つ形にすると、部品⑥の止まる場所が自然に決まり、部品⑤の権限も「読む + 専用の場所に書く」で済みます。

段階 2 ── 設計 1 枚を書く

ここが、私たちが最も重視している段階です。いきなりプロンプトを書いたり、コードを組んだりせず、次の 7 項目を 1 枚に書きます。書けない項目があれば、その項目が「まだ決まっていないこと」です。決まっていないまま作ると、作ってから決めることになり、作り直しになります。

設計 1 枚は、技術文書ではありません。業務を知る人が書き、技術者が読んで「これなら組める」と言える、その間の 1 枚です。開発会社に頼む場合も、この 1 枚を自社で書いて渡すと、見積の精度も出来上がりの精度も変わります。書けない項目を「相談したいこと」として渡すのでも構いません。空欄が見えていること自体が、設計の成果です。

段階 3 ── 部品を組む(手順書 → 道具と権限 → 記憶 → 止まる場所)

設計 1 枚が埋まったら、部品を組みます。順番は、手順書 → 道具と権限 → 記憶 → 止まる場所、をおすすめしています。手順書が先なのは、手順書を書くと「この工程で何を読む必要があるか」が具体的になり、必要な道具と権限が最小の形で決まるからです。道具から先に組むと、使えるものを全部つなぎたくなり、権限が広がります。記憶は、道具と権限が決まった後に「その中で何を覚えるべきか」として設計します。止まる場所は最後に組みますが、設計 1 枚では最初に決まっているので、「後回し」ではなく「実装の順番として最後」です。技術的には、止まる場所は「人の返事が来るまで次の工程に進まない」という単純な仕組みで作れます。難しいのは仕組みではなく、どこに置くかを決めることで、それは段階 2 で終わっています。

段階 4 ── 合格の例で試す

組んだら試します。ここで大事なのは、一発の出来で判定しないことです。AI の出力は揺れるので、1 回うまくいったことも、1 回失敗したことも、それだけでは判定材料になりません。実際の業務から「この入力ならこの出力が合格」という例を、合格と不合格の両方で用意し、手順書を変えるたびに全部を通します。例の数は、最初は両手で数えられる程度でも構いません。大切なのは、例が業務の現物であること(架空の例では本番の外れ方が出ない)と、変えるたびに同じ例を通すこと(前は通っていた例が落ちる、を捕まえる)です。試して外れた例は、多くの場合、手順書に判断基準が足りていない箇所を指しています。外れを「AI の限界」と片付ける前に、手順書の欠落を疑う。この癖が、開発の速度を決めます。

段階 5 ── 本番で直し続ける

合格の例を通ったら、本番の業務で動かします。ただし最初は全件を人が見る期間を置き、差し戻しが減ってきたら例外だけを見る形に移します。「AIエージェント導入の進め方」で「ツールが動いた日は完了ではなく運用の初日」と書きましたが、開発の側から言い直すと、本番で出た差し戻しは、開発の続きの材料です。差し戻しのたびに手順書に判断基準を 1 行足し、合格の例に 1 件足す。これを回すうちに、任せられる範囲が広がっていきます。開発が終わるのは、リリースした日ではなく、この回し方が自社の中で型になった日です。

自社の開発の型 ── 「作る」と「疑う」を分け、動く前に柵を点検する

ここからは一次情報です。私たちは、自社の日常業務を回す AI エージェント群を、自分たちで開発しています。開発の環境としては Claude Code の上に組んでいますが、以下に書く型は環境に依らないものだと考えています。5 つの段階を実際に回す中で固まった、開発の作法を 6 つ挙げます。

1 つ目は、設計 1 枚を先に出して、確認を得てから本生成することです。前のセクションで書いた設計 1 枚は、私たちの中では「作る前の門」として決まりになっています。対外資料でも、社内のエージェントでも、いきなり完成品を作りません。作り直しを分析したところ、無駄になった往復の多くは「暗黙の要件」「手段の取り違え」「求める水準を先に言葉にしていなかった」という、作る前に潰せる種類のものでした。完成品を何度も作り直すより、設計 1 枚を 1 回直すほうが、ずっと安く済みます。この事実が、段階 2 を飛ばさない理由です。

2 つ目は、作る担当と疑う担当を分けることです。実装するエージェントと、それをレビューするエージェントを別に置き、レビュー側は読み取り専用で、直す権限を持たせず、通すか止めるかだけを返させます。作った本人は自分の成果を疑えない、という性質は人も AI も同じで、AI の場合は「作った本人の説明」を読ませると同じ思い込みを共有してしまいます。だから疑う側には成果物と仕様だけを渡します。作る役・試す役・疑う役の分け方は「ソフトウェアテストのAI活用」に詳しく書きました。

3 つ目は、「できました・テストは通りました」の自己申告を信じないことです。エージェントは、実装が完了しテストが通った、と報告してきます。私たちはそれを、別の環境でもう一度実行して確かめます。これは AI を信用していないというより、確率的に動くものの「完了」は、再現して初めて完了になる、という開発上の当たり前を手順にしただけです。段階 4 で書いた「一発の出来で判定しない」の、開発側の実装です。

4 つ目は、柵は動く前に自分で点検し、点検できない日は動かないことです。権限の設定が壊れていると、エージェントは止まるべき場所で止まらずに動きます。壊れていることに誰も気づかないのが最も危ないので、動く前に「自分の柵は立っているか」をエージェント自身に確かめさせ、確かめられなければその日の処理をやめる、という順番にしています。柵を作ることと、柵が効いているかを見る検査は、必ずセットです。

5 つ目は、無人で動く担当は、書ける場所が物理的に縛られていることです。毎朝、人がいない時間に動くエージェントは、決められた隔離フォルダの中にしか書けません。書き出し先の制限は手順書に書くのではなく、環境の側で強制しており、隔離の外へ書こうとすると、費用が発生する処理の手前で止まります。同じ考え方で、1 日に使える量の上限も、エージェント自身が書き換えられない場所に置いています。上限に当たったら、上げずに止まって報告する。上げる判断は人の側にあります。

6 つ目は、差し戻しを「作法」として記録することです。人が差し戻したとき、エージェントは「これは今回限りの調整か、今後も同じ観点で見てほしいか」を 1 問だけ返します。後者なら、その観点を 1 行にして、その担当の作法として記録し、次からは作る前に読みます。読んだかどうかは報告に 1 行出させます。読み飛ばしても出力は普通に出てくるので、読んだことを見えるようにしておかないと、同じ差し戻しが繰り返されるからです。この仕組みがあると、段階 5 の「直し続ける」が、人の記憶に頼らずに回ります。

6 つに共通しているのは、どれも「AI を賢くする」工夫ではないことです。作る前の門、疑う目、再現、柵の点検、物理的な制限、作法の記録。すべて確率的に動くものを、任せられる形に収めるための開発の型です。エージェントの開発が難しいとしたら、その難しさはモデルの扱いではなく、ここにあります。

自社で作るか、開発会社に頼むか、ツールで済ませるか ── 分かれ目は「言語化を誰がやるか」

開発の中身が見えたところで、「誰が作るか」の判断です。AI エージェントを手に入れる経路は、自社で組む、開発会社や構築支援の事業者に頼む、既製ツールで済ませる、の 3 つです。どれが正解ということはありませんが、経路ごとに開発のどの部分を持ってくれて、何が自社に残るかは、はっきり違います。

表の 3 列目を見てください。どの経路でも、業務の言語化、合格の判定、止まる場所の決定は、自社に残ります。これらは技術ではなく、その業務をやってきた人の判断だからです。開発会社に頼めば開発が全部外に出る、という期待は、ここで外れます。逆に言えば、頼む側がこの 3 つを持っていれば、開発会社との仕事は速く進みます。設計 1 枚を自社で書いて渡す、と前に書いたのはこのためです。では、頼む相手をどう選ぶか。事業者に最初に聞く質問を 3 つ挙げます。

• ①「手順書は誰が書き、動かした後の改訂は誰がやりますか」 ── 部品④と段階 5 の担当を確定させる質問です。「AI が自動で学習します」で終わる説明なら、手順書の改訂は自社に残ると読み替えてください。それ自体は悪いことではなく、残ることを知って頼むのと知らずに頼むのが違うだけです。
• ②「合格の判定は、どう作りますか」 ── 部品⑦の有無を確かめる質問です。「実際の業務の例をいただけますか」と聞き返してくる事業者は、段階 4 を持っています。デモの出来の良さだけで説明が終わる場合、本番での外れ方を測る仕組みが無い可能性があります。
• ③「止まる場所と権限は、どの段階で決めますか」 ── 部品⑤⑥が設計の最初にあるか、動いた後の追加になるかを確かめる質問です。最初から聞いてくる事業者は、任せられる状態を作る開発をしています。

フレームワークやツールについて、ひとこと添えます。開発の情報を探すと、まずフレームワークの比較に行き当たりますが、順番は逆です。業務と止まる場所が決まってから、それを最も小さく組めるものを選ぶ。フレームワークを先に選ぶと、フレームワークが得意なことに合わせて業務を探す形になり、任せたい仕事とずれます。私たちは特定の製品を挙げませんが、どれを使うにせよ、この記事の 7 部品と 5 段階は変わりません。道具は変わっても、任せ方の設計は同じです。

AIエージェント開発でつまずく 3 つの型

最後に、開発で実際に起きやすいつまずきを 3 つ挙げます。いずれも「任せる」ための 3 部品を軽く見たときに起こるもので、裏を返せば、設計 1 枚の段階で防げるものです。

この記事では、作る担当と疑う担当を分ける、と書きましたが、複数のエージェントを何を線にして分けるのか、司令塔をどう置くのかは、それだけで 1 本の記事になる設計の話です。別の記事で改めて扱う予定です。 また、合格の例をどう集め、いくつ用意し、どう更新していくかの具体的な手順も、この記事では考え方に留めました。ここで持ち帰っていただきたいのは、作る前に設計 1 枚を書くこと、そして「任せる」ための 3 部品を手順書と同時に組むこと、の 2 つです。

Livune は、「作業を AI に任せる仕組み」を構築している会社です。お客様の AI エージェントを開発・導入支援する側であると同時に、自社の日常業務を自分たちで開発した AI エージェント群で回している側でもあり、この記事の 7 部品・5 段階・6 つの作法は、私たちが自分の会社で使っているものをそのまま書いたものです。

よくある質問