営業のAIが「在庫があります」と返し、出荷のAIが発送を手配する。請求のAIは伝票を作る。
一つずつ見れば、どれも便利です。では、別のお客様の注文も同時に入ったら。同じ在庫を、二つの担当がそれぞれ「使える」と判断していたらどうでしょう。
文章の間違いを直すだけでは、この問題は解けません。必要になるのは、会社全体として守る約束を、仕事の流れに組み込むことです。
AIガバナンスとは、AIに任せる範囲と責任を決め、実際に守れているか確かめ続けること。今回はその中でも、複数の部署やシステムをつなぐ段階で必要になる管理を考えます。2026年9月の動向と、HaruIroAIで作成・実行した説明用の例をもとに、経営者と現場責任者が決めておきたいことを整理します。

9月の動向から見える、管理する範囲の広がり
Microsoftは9月1日の発信で、AIモデルだけでなく、AI・外部の道具・データ・人が関わり合う仕組み全体を管理する方針を示しています。Microsoftの発表
Anthropicも9月15日、小規模企業向けに、会計や顧客対応などをつなぐ業務手順と連携機能を拡充しました。最初は人が承認する設定ですが、業務ごとに自動実行へ切り替える仕組みも説明されています。すべての処理が無人になるわけではなく、最後の実行を人に残す業務もあります。Anthropicの発表
これは、日本の会社でもすぐ同じ仕組みを導入できる、という意味ではありません。ただ、AIが回答を作るだけでなく、外部のシステムを使って仕事を進める方向は、製品として具体化しています。
こうしたAIは「AIエージェント」と呼ばれます。仕事を進めるために道具を選び、場合によっては別のAIへ仕事を渡します。そのとき、個々の担当がうまく動くことと、会社として仕事が正しく終わることは、分けて考える必要があります。
「在庫を見た」と「在庫を確保した」は違う
食品卸の受注を例にします。以下は仕組みを説明するための架空の条件です。顧客で起きた事故でも、特定のAIの性能試験でもありません。
在庫は12箱。二つの注文が、それぞれ8箱入ります。担当Aと担当Bが、在庫を確保する前に同じ「12箱」という数字を見たとします。
どちらも、自分の注文だけなら受けられます。しかし、両方に納品を約束すると合計16箱。4箱足りません。
でも、同じ12箱を使おうとしている。
会社の在庫 12箱
在庫12箱
を確認
在庫12箱
を確認
合計16箱の約束に対し、在庫は12箱。
4箱足りなくなる。
改善の要点:確認と同時に在庫を確保し、次の担当には残りを見せる。どの注文を優先するかは、会社が決める。
この違いを、固定した手順のプログラムで確かめました。「見た数字だけで約束する場合」と「確認と確保を一続きに扱う場合」の比較です。
| 進め方 | この説明例での結果 | 残る仕事 |
|---|---|---|
| それぞれが12箱を見て約束する | 合計16箱を約束し、4箱不足 | 約束した後で納期を調整する |
| 在庫の確認と確保を一続きにする | 先の8箱を確保し、残り4箱。次の8箱注文は保留 | 約束する前に分納や納期を相談する |
プログラムは、この順序を決めて再現したものです。実際の同時アクセスや障害に耐えられるかを検証したものではありません。実行結果と説明用コードも確認できます。
ここで直すべきなのは、AIへの「在庫をよく確認して」という注意だけではありません。在庫を使うと決めた時点で、ほかの担当からは同じ分を使えなくする必要があります。
一方、先に来た注文を優先すれば、経営上も正しいとは限りません。定期契約のお客様を優先するのか、納期が近い注文を先にするのか。分納を提案してよいのか。この判断は会社が決めることです。
システムは、決めた順序や制約を守れるようにする役割を担います。担当AIごとに「売上を最大化」「欠品を避ける」と指示するだけでは、衝突したときの答えがそろいません。
この構造は、予約枠、車両、人員配置にも当てはまります。部署ごとの都合ではなく、会社で共有するものを、どの条件で誰が使えるか。そこが管理の対象になります。
返事がない仕事を、もう一度頼んでよいか
もう一つ、受注から出荷までをつなぐ場面で見落としたくないことがあります。
出荷の依頼は届き、倉庫側では登録が済んだ。しかし、途中で通信が途切れ、AIは返事を受け取れなかった。このとき、AIから見えるのは「返事がない」という状態です。「出荷の登録に失敗した」とは限りません。
失敗したと思って新しく依頼し直すと、同じ出荷が二つ登録される可能性があります。これはAI特有の新しい問題ではなく、以前からシステム連携で扱われてきた課題です。AWSも、返答が届かない場合の再試行と、同じ処理を重ねて実行しない設計を解説しています。AWSの解説
今回の説明用プログラムでも、登録後の返答だけが失われた条件を置きました。新しい依頼として繰り返す方式では出荷記録が2件。同じ処理の再確認として受け付ける方式では1件になりました。
ただし、注文番号を付ければ済むわけではありません。一つの注文でも、分納や数量変更があります。「どの出荷処理を、どの内容で頼んだか」を区別し、受け付ける側が、記録の照合と実際の処理を一体として扱う必要があります。記録をいつまで保持するかも含め、利用する仕組みで確認します。
AIへ「二重に実行しないで」と指示することと、受け付けるシステムが二重実行を防ぐことは、別の対策です。以前の記事では、別の依頼を同じ依頼として扱った問題を取り上げました。今回はその先の、途中まで進んだ取引の扱いを考えます。
失敗に置き換えない。
登録済みなら、その続きから。
元の処理が今後成立しないことを確認して、再依頼を判断。
出荷が進んでいる可能性があるため、在庫を自動で戻したり、新しい出荷として頼み直したりしない。
さらに、途中まで進んだ仕事には後始末が残ります。在庫は確保済み、出荷は登録されたか不明、請求は未作成。ここで一律に「失敗」として在庫を戻すと、出荷が実際には進んでいた場合に、同じ商品を別のお客様へ約束してしまいます。
この場合は、案件を「出荷の状態を確認中」として止め、倉庫の記録を確かめる担当へ渡します。登録済みならそのまま続けるのか、元の処理が今後成立しないことまで確認してから再依頼するのかを決めます。一度検索して見つからなかっただけでは、遅れて処理される可能性が残ります。商品がすでに出ていれば、取り消しではなく回収や顧客対応が必要になることもあります。
AI同士の連携が増えると、こうした途中の状態を扱う機会も増え得ます。監督役のAIを一体置くとしても、実際の記録を確認する方法や、戻せない処理の扱いまで決まっていなければ、仕事全体の責任は引き受けられません。
例外をすべて社長に返すと、自動化はそこで止まる
判断が難しいときに人へ戻す。これは必要ですが、戻し先を決めるだけでは運用は完成しません。その人が、どのくらいの量を引き受けられるかまで考えます。
たとえば説明上、例外が一日に10件あり、一件の確認に15分かかるとします。必要な時間は150分です。責任者が確保している時間が60分なら、単純計算でも毎日6件分が残ります。実際には急ぎの案件や調査の長短もあるため、平均時間だけで判断はできません。
その状態で通常処理だけ速くすると、未処理が積み上がり、納期や顧客への返事が遅れます。見るべきなのは「AIが何件処理したか」に加え、保留が何件あり、最も古いものがいつから止まっているかです。
HaruIroAIでは、こうした業務を設計する際の判断軸として、例外の内容と、引き受ける現場の能力を一緒に考えます。
- 定型的な不足確認は現場担当へ。納期や取引条件を変える判断は、その権限を持つ責任者へ。
- 返事の期限と、不在時の代理を決める。期限を過ぎた案件が一覧に埋もれないようにする。
- 保留が増えたら、新たな自動実行を絞る。すでに受けた案件の引き継ぎと、顧客への連絡は残す。
全員が社長の承認を待つ体制にする必要はありません。会社としての優先順位を先に決め、その範囲で現場が動けること。優先順位そのものを変える必要が出たときに、経営者が判断すること。この分担が、自動化を続けられるかどうかに関わります。
上限と費用も、仕事全体で見る
複数のAIへ仕事を渡すなら、個々の上限だけで全体を抑えられるかも確認します。
説明上、一つの案件を三つの担当へ渡し、それぞれに1万円まで使える設定を与えれば、合計では3万円に達し得ます。会社が意図しているのが「案件全体で1万円」なら、委任先や再実行の分も同じ枠で数える必要があります。
在庫と同じく、残額を別々に見るだけでは同時に使えてしまいます。利用前に枠を確保する仕組みがあるか、上限が単なる通知なのか、実行を止められるのかを確認します。処理中の利用分や、金額が後から確定するサービスの扱いも確認が必要です。
FinOps Foundationの実務記事も、AIが進める手順の変動を踏まえ、費用と手数の上限を論じています。ただし、自社で使う道具が、委任先まで含めた制限に対応しているかは別の確認事項です。AIによる処理の費用管理
費用の評価では、AIの利用料が安かったことだけで成功としない方がよいでしょう。安いモデルに替えて、確認や修正にかかる人の時間が増えることもあるからです。9月10日の同団体の記事も、必要な品質と、成果を一つ得るための費用を判断軸にしています。モデル選択と成果単位の費用
受注なら、何をもって完了と数えるかを先に決めます。たとえば「納期・数量が確定し、必要な伝票が登録され、相手への連絡も済んだ一件」。そのうえで、同じ期間にかかったAI・外部サービスの費用と、人の確認・手直しの費用を合わせ、条件を満たして完了した件数で割ります。
やり直しや未完了に使った費用も、分子から外しません。ただし、月をまたぐ案件が多い仕事では、その月に始めた案件を完了まで追うなど、集計の期間をそろえます。保留件数と遅れも一緒に見ないと、難しい仕事を止めたまま数字だけよく見えることがあります。
新しい使い方を試す費用は、日常業務の費用と分けて扱います。試行には失敗から学ぶ価値がありますが、運用に移すなら、必要な品質・費用・引き受けられる例外の量を満たすか、改めて判断します。
まず一つの業務で、止まった後まで決める
すべての会社に、大掛かりな管理システムが必要なわけではありません。AIが文章の下書きだけを作り、人が実際の登録を行う仕事なら、今回の対策を一式増やす必要はありません。
一方、在庫、予約、請求、顧客連絡までAIにつなごうとしているなら、導入前に一つの業務を選び、次の記入票を使ってみてください。
業務の確認メモ(コピーできます)
【複数の担当をつなぐ業務の確認メモ】
仕事の名前/どこからどこまで任せるか:
1. 完了:何が実際にできたら一件完了か。
どのシステムの記録で確認するか:
2. 共有:在庫・予約枠・予算のどれを共有するか。
同時に使われない仕組み/競合したときの優先順位:
3. 途中:返事がなく、実行済みか不明なときの照会先。
再実行できる条件/取り消せない処理の引受先:
4. 例外:誰が、いつまでに、何件程度引き受けられるか。
不在時の代理/自動実行を絞る条件:
5. 費用:委任先・再実行を含めた全体上限。
完了一件の費用/保留件数と最も古い保留の経過時間:
出荷の例なら、3番には「照会先は倉庫担当。状態が不明な間は在庫の確保を維持する。元の処理が今後成立しないことまで確認してから、再依頼を判断する」と書きます。確認に時間がかかる場合の顧客連絡は、4番の担当と期限につなげます。
「返事が来なかった」「担当者が不在だった」「二つの注文が同時に入った」という場面を、取引を発生させない試験環境で確かめます。図に責任者の名前があるだけでなく、止まった案件をその人が引き取れるところまでが確認の範囲です。
記録は、案件・行った処理・結果・現在の状態・次の担当が追えるようにします。顧客の資料やAIの思考の全文を、何でも複製して残すという意味ではありません。
資料をAIに渡す段階の整理は会社の資料、AIにどこまで見せていい?で、対外送信の確認はAIが作った見積もりを送る前の確認で扱っています。今回は、その先で仕事がつながった後の運営を考えました。
AIを増やせば、人の仕事が一様になくなるわけではありません。個々の作業を進める役割から、部署の都合を調整し、未完了を解き、仕事全体の採算を確かめる役割へ、人の担当が変わる部分があります。
はるいろAI活用支援では、現場の業務や人員配置を踏まえ、どこをAIに任せ、どこを人が引き受けるかを一緒に整理します。部署をまたぐ仕事のつなぎ方に迷っている場合は、サービス内容をご覧ください。
この記事の根拠と範囲
2026年9月23日に確認したMicrosoft・Anthropic・AWS・FinOps Foundationの一次情報をもとに、HaruIroAIが業務運営の観点で整理しました。固定した条件の説明用プログラムを作成・実行しています。実顧客の事例、AIの性能試験、実際の外部サービスの障害試験ではありません。構成・調査・文章化にAIを使用し、公開前に人が内容を確認しています。