AIに社内の道具を使わせる5工程｜任せる範囲を関数で決める

「今月の配信状況を聞いたのに、去年の数字で答えられた」「社内の在庫を見てほしいだけなのに、それらしい数字を作って返してくる」——生成AIを業務に入れた担当者から、こうした声がよく上がります。原因は賢さの不足ではありません。本当は、AIに社内の仕組みを呼びに行かせる経路がないだけです。そして、その経路を作る作業は技術の話である前に、どの業務までをAIに任せ、どこから先は人が確定させるかを決める設計です。この記事では、呼び出し1本を組み立てる5つの工程と、任せる範囲の引き方を順に見ていきます。

「今月の配信状況を見て」と頼んで、去年の数字が返ってきた

社内の話を生成AIに聞くと、体裁は整っているのに中身が合っていない、ということが起きます。これは知識量の問題ではありません。モデルが答えを作るときに見ているのは学習した時点までの一般的な文章だけで、自社の配信基盤にも在庫の台帳にも商談の記録にも触れていないからです。触れていないものを聞かれれば、形だけを整えた答えが出ます。

ここで多くの担当者が最初にやるのが、指示文の書き直しです。「推測しないで」「分からなければ分からないと答えて」と条件を足していく。まったく効かないわけではありませんが、根本には届きません。見に行く手段が渡されていないものは、どれだけ丁寧に頼んでも見に行けないからです。足すべきなのは言葉ではなく、社内の仕組みを起動する経路のほうです。

この経路のことを、実装の世界ではファンクションコーリングと呼びます。日本語にすれば関数を呼ぶこと、つまりあらかじめ用意しておいた処理を、AIの判断で起動させる仕組みです。名前だけを見ると開発者向けの話に見えますが、決めごとの大半は業務側にあります。何を呼ばせるのか、どこまでを任せるのか。技術の細部よりも、そちらのほうが結果を左右します。

呼びに行くAIは、動作のどこが違うのか

違いは、たとえ話をしなくても4つの往復で説明できます。第1に、こちら側が質問と一緒に「使える道具の一覧」をAIに渡します。第2に、AIは答えの代わりに「この道具を、この項目で呼んでほしい」という要求を返します。第3に、こちら側の仕組みが実際にその処理を動かします。第4に、結果をAIに戻すと、AIがそれを読んで日本語の答えに組み立てます。

重要なのは、第2と第3のあいだに必ずこちら側のプログラムが挟まっていることです。グーグルの公式ドキュメントは、モデルは関数そのものを実行しない、名前と引数を取り出して自分のアプリケーションの中で実行せよ、と明記しています。アンソロピックの資料でも、モデルが返すのは呼び出しの要求であり、実行して結果を返すのは呼び出し側のコードだと説明されています。

つまりAIは、社内の仕組みに直接触っていません。触っているのはこちらのコードです。だから「AIに何をさせないか」は、AIへの言い聞かせではなく、コードの側で確定できることになります。ここが、指示文だけで安全を担保しようとする発想との決定的な違いです。禁止事項を書き並べる前に、そもそも渡さない、という選択肢が取れます。

往復は1回とは限りません。グーグルの公式ドキュメントは、互いに独立した処理であれば複数の道具を同時に呼べること、そして前の呼び出しの結果を使って次の呼び出しを組み立てる連鎖ができることを説明しています。実務でも、在庫を照会してから納期を照会する、といった形で自然にこの形になります。1回の問いかけに対して呼び出しが何本走るかは、渡した時点では分からないという前提で、1本ずつに上限を持たせておく必要があります。

道具の一覧は、質問のたびに丸ごと送られている

見落とされやすいのが、道具の説明が「どこに置かれているか」です。一覧はAIの中に保存されているわけではありません。質問を送るたびに、名前・説明文・項目の定義がまとめて一緒に送られます。アンソロピックの資料は、料金の計算に道具の定義そのものが含まれると明記しており、説明文が長ければその分の費用が毎回かかります。

費用よりも効いてくるのが、判断の材料としての意味です。AIが道具を選ぶときに見ているのは、実際の処理の中身ではありません。そこに書かれた説明文だけです。処理がどれほど正確に作られていても、説明文が曖昧なら選び間違えます。逆に言えば、選ばせ方の品質は、業務を知っている人が書いた文章の品質でほぼ決まります。

この事実は、役割分担にも影響します。処理の中身は開発側が作りますが、説明文はその業務を毎日回している人でないと書けません。いつ使う処理なのか、どういうときに使ってはいけないのか、何が返らないのか。これらは仕様書には書かれていない現場の知識です。開発に丸投げすると、ここが空欄のまま動き始めます。

呼び出し1本は、4つの部品でできている

道具を1つ用意するというのは、次の4つを決めることです。どれか1つでも欠けると、選び間違いか事故のどちらかにつながります。

部品	そこに書くこと	主に決める側
名前	どの仕組みの、何をする処理かが分かる短い呼び名	業務と開発の合意
説明文	何をするか、いつ使い、いつ使わないか、何を返さないか	業務側
渡す項目	処理に必要な値と、その型・選択肢・必須かどうか	業務と開発の合意
返る形	呼んだ結果として何を返し、何は返さないか	開発側と業務の合意

名前には形式上の制約もあります。アンソロピックの仕様では、英数字と一部の記号で64文字以内と決まっています。短い制約に見えますが、複数の仕組みをつなぐと名前は必ず衝突します。公式資料は、どの仕組みのものかを名前の頭に付ける書き方を勧めています。社内の言い方でいえば、「照会」ではなく「在庫台帳の照会」と名乗らせるということです。

5工程の全体像

ここから先が本題です。呼び出しを1本組み立てるとき、決める順番は次の5つになります。順番を入れ替えると、後の工程で前の決定を壊すことになります。

工程1：どの業務を1つの道具として切り出すか

5工程の中で、外注もツール選定も代わりにやってくれないのがこの工程です。業務のどこに線を引いて1つの単位にするか。この線が、あとから付ける権限の単位にも、記録に残る単位にも、承認を挟む位置にもそのままなります。道具の切り出しは、任せる範囲の設計そのものだと考えたほうが正確です。

切り方には2つの向きがあります。1つは、細かすぎるものをまとめる向きです。アンソロピックの資料は、行為ごとに別々の道具を作るのではなく、関連する操作を1つにまとめて「どの操作か」を項目で指定させる形を勧めています。作る・見る・確定するを3本に分けると、似た説明文が並んで選び間違いが増えるからです。

もう1つは逆に、戻せる操作と戻せない操作は、たとえ隣り合っていても分ける向きです。まとめる利点は選びやすさですが、まとめてしまうと権限も承認も同じ扱いになります。台帳を見るのと台帳から消すのを1本にすると、見るために渡した許可が消すことまで含んでしまいます。まとめる基準は業務の近さ、分ける基準は取り返しのつくかどうかです。

切り出しの粒度を決める3つの問い

線を引く場所に迷ったら、次の3つを順に当ててみると決まります。どれか1つでも答えられないなら、その単位はまだ道具にすべきではありません。

• この単位で失敗したとき、何がどこまで元に戻せるのかを言えるか
• この単位に「誰が使ってよいか」を付けられるか。付けられないなら業務としてまとまっていない
• 記録に残したときに、後から見た人が何をしたのかを1行で読み取れるか

3つ目は軽く見られがちですが、運用に入ってから効いてきます。記録が「処理を実行した」としか残らない粒度だと、何かあったときに追えません。逆に、1回の呼び出しが業務の1つの意味とそろっていれば、記録はそのまま業務の履歴になります。切り出しの粒度を決めることは、監査の粒度を決めることでもあります。

もう1つ、社内で合意しておくとよいのが呼び名です。同じ処理を部門ごとに違う言葉で呼んでいると、説明文も揃わず、似た道具が二重に作られます。呼び出しを作る前に、その業務の名前を1つに決める。地味ですが、これをやらないまま数が増えると収拾がつかなくなります。

工程2：道具の説明文を書く

アンソロピックの公式資料は、説明文について踏み込んだ書き方をしています。きわめて詳しい説明を書くこと、これが道具の性能を決める最大の要因である、と明記したうえで、1つの説明文につき最低でも3文から4文、複雑な処理ならさらに長く書くことを勧めています。1行の要約では足りない、という趣旨です。

同じ資料は、説明文に入れるべき中身も4つ挙げています。第1に、その道具が何をするか。第2に、どういうときに使い、どういうときには使ってはいけないか。第3に、それぞれの項目が何を意味し、挙動をどう変えるか。第4に、注意点や限界、とくにこの道具が返さない情報は何か。この4つ目が抜けている説明文が、実務では圧倒的に多いところです。

グーグルの公式ドキュメントも同じ方向で、明確かつ具体的に書くこと、空白や特殊な記号を含まない分かりやすい名前を使うことを挙げています。どちらの資料も、書き方の細かい流儀ではなく「読んだだけで使いどころが判断できるか」を基準にしています。判断できないなら、それは説明文ではなく見出しです。

説明文が雑だと、選び間違いが起きる

実際に起きる崩れ方は決まっています。次のような説明文は、動作の確認では問題が出ず、運用に入ってから静かに間違い続けます。

• 「在庫を取得する」だけ：いつ使うのか、何を返さないのかが書かれておらず、似た道具と取り違える
• 社内の通称だけで書く：呼び名の意味が説明文の中で完結しておらず、別の道具が選ばれる
• できないことを書かない：過去分は返らない処理なのに、過去を聞かれたときにも呼ばれて空が返る
• 「必要なときに使う」と書く：判断の材料がゼロで、呼ぶかどうかがその場の運任せになる

直し方は難しくありません。良い説明文は、たとえば在庫の照会なら「指定した品番の、現時点の引き当て可能数を返す。取り置き済みの数は含まない。過去の在庫推移は返らないので、推移を聞かれたときはこの道具を使わない」といった形になります。返らないものを先に書くだけで、選び間違いはかなり減ります。

説明文を誰が確認するかも決めておきます。開発側だけで書くと第1と第3しか埋まらず、業務側だけで書くと項目の意味が曖昧になります。実務では、業務側が下書きを書き、開発側が項目の説明を補い、最後に業務側がもう一度読む形が回ります。生成AIに下書きを整えさせるのは構いませんが、「使ってはいけない場面」を書けるのは人だけです。

文章では伝わりにくい項目には、入力の例を添える方法もあります。アンソロピックの仕様には、その道具に対する正しい入力の例をいくつか並べて一緒に渡す仕組みがあり、入れ子になった項目や書式に厳しい項目で効くと説明されています。費用の目安も示されていて、単純な例で1つあたりおよそ20から50、入れ子の複雑な例でおよそ100から200の単位が加わります。説明文を長くするより、例を1つ足したほうが速く伝わる場面があるということです。

工程3：渡す項目を決める

項目を決めるときの原則は1つで、その場で決まるものだけを渡すことです。呼び出し元ですでに分かっている値、たとえば呼んでいる人の所属や対象の部門番号は、AIに埋めさせずこちら側のコードで付けます。埋めさせる項目が増えるほど、間違った値が入る余地が増えます。

グーグルの公式ドキュメントは、汎用の型ではなく整数・文字列・選択肢といった具体的な型を使うことを勧めています。選択肢で値を固定すれば、想定していない文字列が入ってくること自体がなくなります。件数の上限、対象にできる期間の長さ、対象にできる区分。これらは説明文でお願いするのではなく、項目の型で縛るのが確実です。

必須と任意の分け方にも意味があります。必須にした項目は、値が決まらない限り処理を呼べません。つまり必須の指定は、そのまま安全装置になります。逆に、なんとなく任意にしておいた項目に既定値を持たせていると、誰も指定していないのに既定値で処理が走ることになります。既定値を置くかどうかは、その値で動いても困らないかで決めます。

定義どおりに呼ばせることを、設定として強制する手段もあります。アンソロピックの仕様には、道具の定義に厳密な適合の指定を加えることで、呼び出しの中身が定義どおりであることを保証する仕組みがあります。この指定を入れると、想定していない項目名や型のずれが呼び出しの段階で起きなくなります。検証で弾く手当ても要りますが、その前にそもそも定義から外れたものを作らせないほうが確実です。

埋まっていない項目は、推測で埋められることがある

ここは実務で最も事故につながる挙動なので、公式資料の記述をそのまま押さえておく価値があります。アンソロピックのドキュメントは、必要な項目を埋めるだけの情報が質問に含まれていない場合、モデルが不足に気づいて聞き返すこともあるが、それらしい値を推測して埋めることもあると明記しています。示されている例では、場所を指定せずに天気を尋ねたところ、指定していない都市名と単位が入った状態で呼び出しが組まれています。

天気なら害はありませんが、業務では別です。対象期間が勝手に埋まれば違う月の数字が返り、送信先が勝手に埋まれば別の相手に届きます。しかも呼び出し自体は正常に成功するので、画面上はエラーにならず、間違った結果だけが返ってきます。これが、指示文の工夫では防ぎきれない類の失敗です。

• 必須にすべき項目は必須として宣言する。任意にしたうえで説明文で頼むのは弱い
• 値の候補が決まっているものは、自由入力にせず選択肢にする
• グーグルの公式ドキュメントは、処理を実行する前に呼び出しの内容を検証することを勧めている。範囲外の値はこちら側で弾く
• 足りないときは呼ばずに聞き返す動きにする。埋めさせるより、止めるほうが安全

同じ資料には、この挙動がモデルによって違うことも書かれています。能力の高いモデルほど、必要な項目が足りないことに気づいて聞き返す傾向が強く、軽いモデルほど、それらしい値を入れて先に進む傾向がある、という説明です。つまり試作で使ったモデルと本番のモデルが違えば、同じ設計でも挙動が変わります。費用を下げるために軽いモデルへ切り替えるときは、必須の項目まわりを必ず確認し直します。

検証をどこに置くかも決めておきます。AIに検証させるのではなく、処理を動かす直前のコードで確かめるのが原則です。AIは検証を頼まれれば通ったと答えることもできてしまうため、判定を任せると安全装置になりません。範囲の確認、対象の存在確認、上限の確認は、機械的な条件として書きます。

工程4：返ってくる形を決める

返す側の設計は軽視されがちですが、次の一手の質を直接決めます。アンソロピックの資料は、信号の強い情報だけを返すよう設計せよと書いています。内部でしか通じない参照番号ではなく、意味が読み取れて安定した識別子を返すこと。そして、次の判断に要る項目だけを含めること。膨らんだ返り値は文脈を食い、要点を取り出しにくくする、と明記されています。

実務では、台帳の1行をそのまま全部返してしまう作りをよく見ます。使わない列まで返ると、費用が増えるだけでなく、本来なら見せなくてよい中身が答えの材料に混ざります。取引先の与信区分や個人の連絡先が、聞かれてもいないのに文脈に入ってしまう、という形の漏れ方です。返す項目を絞ることは、情報を守る作業でもあります。

件数の上限も返す側で決めます。上限を決めずに全件返す作りにすると、対象が広い問い合わせが来たときに一気に膨らみます。返す件数の上限と、続きがあることの伝え方を最初に決めておけば、あとから慌てて絞る必要がなくなります。上限を超えたときに何を返すかも、失敗ではなく正常の一形態として設計します。

工程5：失敗したときの扱いを決める

呼び出しは失敗します。対象が無い、取りに行けない、時間内に返らない、返ってきたが値がおかしい。この4つを別々に扱えるようにしておくと、後の運用がまったく違います。まとめて「エラー」で返すと、AIは何度も同じ呼び出しをやり直すか、別の道具を試し始めます。

起きたこと	返す内容	その後にさせること
対象が無かった	該当なしと分かる返り値	その旨を答えさせる。別の道具を試させない
取りに行けなかった	失敗と分かる返り値と理由	決めた回数だけやり直し、超えたら止める
時間内に返らなかった	打ち切ったことが分かる返り値	人に回す。待ち続けさせない
値がおかしかった	検証で弾いたことが分かる返り値	答えの材料に使わせない。人に上げる

やり直しの回数と待ち時間の上限は、道具ごとに数字で決めます。決めていないと、うまくいかない呼び出しほど長く粘ることになり、費用も待ち時間も膨らみます。やり直しは2回まで、待ち時間は何秒までといった形で、業務の許容時間から逆算して置くのが実務的です。打ち切った後の行き先も一緒に決めます。

書き込む道具では、もう1つ決めることがあります。同じ呼び出しが2回届いたときの扱いです。時間内に返らなかった呼び出しは、実際には処理が通っていて返事だけが届いていない、ということがあります。ここで素直にやり直すと、二重に登録されます。実務では、呼び出しごとに一意の札を持たせ、同じ札の呼び出しが再び来たら処理をせずに前回の結果を返す作りにします。この手当てがないと、やり直しの設定がそのまま二重処理の設定になります。

もう1つ大事なのが、失敗を成功の形で返さないことです。取りに行けなかったときに空の結果を返すと、AIは「該当なし」と読み、自信を持って「ありません」と答えます。これは間違いの中でも見つけにくい部類です。空の結果と、取りに行けなかったことは、返り値の段階で必ず区別します。

取り消せる操作と、取り消せない操作を分ける

ここからが、任せる範囲の線引きです。判断の軸は権限の大小ではなく、取り返しがつくかどうかに置きます。読むだけの道具は、間違って呼ばれても元に戻す作業が要りません。書き込む道具は、書いた内容を戻せるかどうかで扱いが変わります。

戻せない操作の代表は、送金、削除、社外への送信、公開です。この4つは、AIが呼び出しを組み立てるところまではやってよいとしても、確定させる操作は人の手に残します。形としては、AIに渡すのは「下書きを作る」「予約を入れる」までの道具にして、実行は人が画面で押す。呼び出しの設計の段階で、ここを分けておくのがいちばん確実です。

呼ぶかどうかそのものを、設定で制御することもできます。アンソロピックの仕様では4通りの指定ができ、AIに任せる、必ずどれか1つは呼ばせる、この道具を呼ばせる、いっさい呼ばせない、が選べます。グーグルの公式ドキュメントにも、任せる・必ず呼ばせる・呼ばせないの3つの設定があります。場面ごとに、任せる度合いを切り替えられるということです。

使い分けの例を挙げます。問い合わせに答える画面では任せる設定にし、締めの処理を扱う画面では特定の道具だけを呼ばせる。逆に、社外向けの文面を書かせる画面ではいっさい呼ばせない設定にして、社内の情報が混ざらないようにする。呼ぶかどうかを、毎回AIに判断させる必要はありません。画面や場面の単位で先に決めておけば、判断そのものの回数を減らせます。

承認を挟む位置も、道具の切り出し方で決まります。1本の道具の中に確定まで含めてしまうと、承認を挟む場所が消えます。逆に、案を作る道具と確定する道具を分けておけば、確定する側だけ人の操作にできます。後から承認を足せる構造にしておくことが、切り出しの段階での実質的な判断になります。

マーケ業務で、呼ばせてよいもの・よくないもの

抽象論だけでは線が引けないので、マーケティングの現場でよくある処理を3つに仕分けてみます。自社で作るときの叩き台として使えます。

• 配信の予約状況の照会：いつ何が送られる予定かを返すだけ。読むだけなので戻す必要がない
• 在庫と納期の照会：品番を指定して現時点の数を返す。資料や回答の裏取りに効く
• 商談記録の検索：条件に合う記録の在りかを返す。中身の要約は別の判断
• 担当者の空き枠の照会：予定を取るのではなく、空いている時間を返すだけにする

次が、呼ばせてよいが確定は人が押す層です。やり直しはきくが、影響が社内に及ぶものがここに入ります。配信の停止、担当者の割り当ての変更、見込み客の段階の付け替え。いずれも間違えても復旧できますが、復旧のあいだ現場が混乱します。案としてAIに組ませ、押すのは人にします。

• 顧客への一斉送信の実行：送った後に取り消せない。宛先の誤りが外に出る
• 名簿や記録の削除：戻せない。しかも消えたことに気づくまでに時間がかかる
• 社外への共有リンクの発行：発行した瞬間に自社の管理外に出る
• 値引きや条件の確定：金額の判断は事実の取得ではなく、意思決定にあたる

実務仕様の一覧：道具1つあたりに決める項目

最後に、道具を1本追加するときに埋める項目をまとめます。この一覧が埋まらない道具は、まだ渡さないという運用にすると、増やしすぎと事故の両方を抑えられます。

• 名前（どの仕組みの何をする処理かが読み取れること）
• 説明文（何をするか。3文から4文以上）
• 使ってはいけない場面（1つ以上、具体的に）
• 返さない情報（この道具の守備範囲の外を明示する）
• 渡す項目と、それぞれの型・選択肢
• 必須の項目と、任意の項目の既定値
• 件数・期間・対象範囲の上限
• 返す項目と、識別子の形
• 失敗の型ごとの返り値（該当なし／取得失敗／打ち切り／検証で弾いた）
• やり直しの回数と、待ち時間の上限
• 取り消せる操作か。取り消せないなら、確定を人に残す位置
• 記録に残す項目と、見直しの時期

運用に入った後は、記録から3つを見ます。呼ばれた回数、失敗の型ごとの件数、そして呼ばれるべきだったのに呼ばれなかった問い合わせです。3つ目は記録に直接は出ないので、答えの外れた事例を拾って説明文に反映します。説明文の直しは、処理を作り直すより軽く、効き目は大きい作業です。

見直しの時期も先に決めておきます。業務の手順が変われば、返らない情報も、使ってはいけない場面も変わります。手順が変わったら説明文も直すという組み合わせを運用の側に置いておかないと、説明文だけが古いまま残り、静かに選び間違いが増えていきます。

まとめ

AIに社内の道具を使わせるというのは、賢い仕組みを載せることではありません。実行するのはAIではなく、こちら側のコードです。AIが任されているのは、渡された説明文を読んで呼ぶかどうかを決めるところまで。だから設計の中心にあるのは、どの業務をひとかたまりとして切り出し、その説明文に何を書き、どの項目までを埋めさせるか、という業務側の判断になります。

5つの工程は、業務を切り出す、説明文を書く、渡す項目を決める、返る形を決める、失敗時を決める、の順に進みます。説明文には返らない情報と使ってはいけない場面を必ず書き、渡す項目はその場で決まるものだけに絞り、埋まっていない項目が推測で埋まる前提で検証を置く。そして送金・削除・社外送信・公開は、案までをAIに任せ、確定は人が押す。この線を先に引いてから、最初の1本を作り始めてください。

※本記事にはAIが活用されています。編集者が確認・編集し、可能な限り正確で最新の情報を提供するよう努めておりますが、情報の完全性、正確性、最新性、有用性等について保証するものではありません。本記事の内容に基づいて行動を取る場合は、読者ご自身の責任で行っていただくようお願いいたします。