AIの試作を本番へ移す前の10問｜鍵・権限・上限・停止を先に決める

元になった公開情報

「AIの試作を本番へ移す前に、すべてのスタートアップが答えるべき10の問い」という記事が、2026年8月21日にGoogle Cloudのブログへ掲載されました。著者はGoogle Cloud AIのSergio Villani氏です。内容はGoogle Cloudの製品を前提としており、対象読者もスタートアップの開発者です。

原文はスタートアップ向けですが、そこで挙げられている失敗は、社内に開発の専任者がいない中堅企業でも起こり得るものです。原文が示す具体例を引用します。

• 流出したAPIキーが、48時間で高額な請求を積み上げる
• AI Studioから別基盤への「すぐ終わる」移行が、IAM（アクセス権管理）の担当者が社内に不在という理由で数週間止まる
• 公開はうまくいったが、プロジェクト単位の既定のクォータによってHTTP 429（要求が多すぎる）を返すようになり、追加費用なしに容量を増やす手段がない
• 月に180ドル程度しか使っていないアカウントのAPIキーが公開リポジトリから収集され、数万ドル規模の請求が積み上がってから最初の請求アラートに気づく

いずれも、モデルの精度そのものとは別の問題です。移行の途中で表面化するものも、公開後に表面化するものもあります。共通しているのは、試作の成否を判断する段階では議論の対象になりにくいという点です。

原文の10問は、Onboard（最初の1時間で土台を正す）、Scale（割高な支払いをせずに容量を増やす）、Govern（費用・鍵・エージェントを統制する）の3段階に整理されています。

中堅企業向けに読み替えた10問

原文はクラウド事業者と製品名を前提としており、設問も同社のサービス選択や課金方式に踏み込んでいます。そのままでは自社の稟議に使えません。以下は、原文の論点を出発点に、社内へ開発の専任者がいない中堅企業向けにGXOが組み直した10問です。原文の10問と一対一で対応するものではなく、利用モードの選択やバッチ処理の振り分けといった製品固有の設問は外し、入力データの条件、出力の確認、障害時の連絡、停止手順を加えています。

1. 本番環境と検証環境は分かれているか 同じアカウント、同じプロジェクト、同じデータで試作と本番を動かしていないかを確認します。分かれていない場合、検証中の操作が本番のデータや請求に影響します。

2. 認証情報はどこに置いているか APIキーや接続情報を、ソースコード、設定ファイル、共有フォルダ、チャットの履歴に置いていないかを確認します。原文も「.envファイルに置かないこと」を明示しています。置き場所と、誰が取り出せるかを決めてください。

3. 権限を管理する担当者は誰か アクセス権の設計と変更を誰が行うかが決まっていないと、移行や障害対応のたびに止まります。兼任でも構いませんが、名前が入っている必要があります。

4. 利用量が増えたときの上限を確認したか 上限の仕組みはサービスによって異なります。プロジェクトごとの固定値がある場合もあれば、原文が説明するように、固定の上限値を持たず共有された容量を使う方式で、混雑時に一時的に処理が拒否される場合もあります。自社が使う方式で、何が起きたときにどうなるのかを確認してください。エラーで止まるのか、待たされるのか、追加課金になるのかで、業務への影響が変わります。

5. エラー時の再試行と打ち切りを設計したか 応答が返らないとき、何回まで再試行し、何秒で諦めるかを決めます。無制限に再試行する実装は、障害時に費用と負荷を増幅させます。

6. 費用の上限を設定したか 原文が区別しているのは、通知を送る仕組みと、実際に利用を止める仕組みです。原文で紹介されている支出上限の機能については、公開時点でプレビューであること、到達率50%と80%でも通知は出ること、強制は即時ではなく推定コストに基づくこと、上限を超えた分は通常どおり課金されること、そして1つの上限が対象とするのは1つのプロジェクトの1つの対象サービスであってアカウント全体の保護ではないこと、解除後のサービス再開に最大1時間かかり得ることが記載されています。自社が設定しているのが通知だけなのか停止まで含むのか、そして何を対象とした上限なのかを確認してください。

7. 入力してよいデータの条件を決めたか 個人情報、顧客の機密情報、未公開情報を入れてよいかを、用途ごとに決めます。決めていない状態で現場に開放すると、何が入ったか後から追えません。

8. 出力の妥当性を誰がどう確認するか 出力をそのまま業務に使うのか、人が確認するのかを決めます。確認する場合は、確認者と確認の基準を決めます。

9. 障害時の担当と連絡経路が決まっているか 夜間・休日を含めて、誰が最初に気づき、誰が判断するかを決めます。外部に委託している場合は、その連絡先と応答時間を確認します。

10. 止める手順が決まっているか 何が起きたら止めるか、誰が止められるか、止めたときに業務をどう回すかを決めます。ここが空欄のまま本番へ出てしまう例は、相談の場でもたびたび見かけます。

発注仕様と検収証拠へ変換する7項目

10問へ「はい」と答えるだけでは、委託先との認識は揃いません。発注書には実装条件を、検収条件には確認できる証拠をセットで書きます。

「設定する」ではなく、何を受け取れば設定済みと判断できるかまで合意することが、追加費用と責任の押し付け合いを防ぎます。

埋まらない項目が示していること

この10問を会議で配ると、2番、3番、6番、10番で手が止まることがあります。空欄が何を示唆するかは、項目によって異なります。

このうち10番は、AIに限らずすべてのシステムに当てはまる項目です。AIの導入をきっかけに、既存システムの停止手順が決まっていなかったと分かる場合もあります。

稟議書に書くべき5行

経営会議や稟議で本番化の承認を求める際、次の5行を入れると議論が短くなります。

1. 対象業務と、AIが担当する範囲（人が担当する範囲との境目）
2. 月額の上限と、超過時にどうするか
3. 入力してよいデータの条件
4. 障害時の対応者と、業務の代替手段
5. 効果を判定する時期と、続けない場合の条件

5行目が特に重要です。開始の条件だけを決めて終了の条件を決めない導入は、成果が出なくても止まりません。試行期間と、続けない判断の基準を先に書いてください。

費用が想定を超える典型パターン

原文が挙げている流出したAPIキーによる高額請求は極端な例ですが、通常の運用でも費用は想定を超えます。よくある原因は次のとおりです。

• 想定より長い文書が入力される（利用者が資料を丸ごと貼る）
• 再試行の設定が緩く、失敗時に同じ処理が繰り返される
• 検証環境の処理が止められないまま動き続ける
• 一部の利用者が大量に使う（全社平均で見積もると外れる）
• 対話の履歴を毎回すべて送る実装になっている

これらは設計で抑えられます。導入前に、1件あたりの処理量の上限、1人あたりの上限、月次の上限をそれぞれ決めておくのが実務的です。

発注している場合に確認すること

外部の開発会社に委託している場合、上記の10問のうち技術面は委託先が設計します。ただし、次の点は発注側で確認してください。

• 認証情報を誰が保有し、契約終了時にどう扱うか
• 上限額の設定を誰が行い、変更に誰の承認が要るか
• 障害時の連絡先と、応答時間の取り決め
• 利用状況と費用の内訳を、どの頻度で報告してもらうか
• 委託先が別のサービスを組み合わせている場合、その一覧

最後の項目は見落とされやすいところです。委託先が複数の外部サービスを組み合わせて構築している場合、依存する先が増えます。契約の当事者が誰になるかは構成によりますが、一覧がないと、解約や乗り換えの際に何が止まるか分かりません。

エージェントを業務システムへ接続する場合、権限は次の四層に分けて確認します。

本番化の判定を誰がするか

PoCから本番へ進むかどうかの判定を、開発した部門だけで行う体制には注意が必要です。作った側は動いたこと自体を成果と捉えやすく、運用や費用の観点が抜けやすいためです。

観点ごとに見る人を分けておくと、抜けを見つけやすくなります。実務的な形は次のとおりです。

小規模な会社では、複数の役割を同じ人が兼ねることになります。それでも、観点として分けて確認することに意味があります。同じ人が上の観点を順に見るだけで、抜けは減ります。

PoCが本番に進まない典型的な理由

判定の場を作っても、そこに上がってくる前に止まっている案件があります。よくある理由を挙げます。

理由1：使う人が決まっていない 「便利そうだから作ってみた」で始まった案件は、日常業務に組み込む人が決まっていません。誰の、どの作業を置き換えるのかが決まっていない案件は、本番化の判断以前の段階にあります。

理由2：既存システムとつながっていない 試作では手作業でデータを用意していたが、本番では既存システムから取得する必要がある、というケースです。この連携部分に想定以上の工数がかかることがあります。試作の段階で連携の可否と方式を確認しておかないと、本番化の見積りが試作時の想定から大きく動きます。

理由3：例外処理を決めていない うまくいく場合だけを試して終わっている案件です。入力が想定外だった場合、出力が明らかに誤っている場合、サービスが応答しない場合にどうするかを決めていないと、業務に載せられません。

理由4：費用の負担部門が決まっていない 試行期間中は情報システム部門の予算で動かしていたが、本番後は誰が払うのかが決まっていない、という状況です。金額の大小ではなく、決まっていないこと自体が意思決定を止めます。

あわせて確認したい点：やめる条件がない 続けるか判断する時期が決まっていないため、成果が出ないまま費用だけが続くことがあります。これは本番化を止める理由ではありませんが、次の案件の予算を圧迫します。

稟議の前に用意する試算表

本番化の稟議では、次の6行の試算があると議論が具体化します。

1. 現在の作業：対象人数 × 1件あたりの時間 × 月間件数
2. 導入後の想定：同じ計算式で、想定される時間
3. 差分の金額換算（時間あたりの人件費で換算）
4. AIの利用料（想定利用量での月額、上限額）
5. 運用の工数を金額換算したもの（確認、修正、問い合わせ対応の時間 × 時間あたりの人件費）
6. 差引の効果（3から4と5を引いたもの）

5行目を入れることが重要です。AIを使うと、出力を確認する作業が新たに発生します。この工数を計上しないと、効果が実態より大きく見えます。ただし、確認工数を入れても差引の効果が残ることは、本番化の必要条件であって十分条件ではありません。情報の取り扱い、品質、可用性、法令上の要請など、金額に表れない論点は別途判断してください。

3か月後に見直す項目

本番化した後、3か月程度で一度見直す項目を決めておいてください。導入直後は関心が高く、時間が経つと誰も見なくなるためです。

本番化前の90日も、次の四つのゲートに分けます。日数は標準工期ではなく、判断を先送りしないためのGXOの進行例です。

46〜70日目の統制設定を「公開後に行う」とする提案は、差し戻してください。稼働後の改修は、止められない業務を抱えた状態で行うことになるためです。

• 実際の利用状況（想定した部門・人が使っているか）
• 実際の費用（試算との差、その原因）
• 出力の確認で見つかった問題の件数と傾向
• 現場からの要望のうち、対応していないもの
• 停止や障害の発生と、そのときの対応の実際

このうち3番目の傾向を見ると、次に改善すべき点が分かります。件数が減っていなければ、業務手順の側に問題がある可能性があります。

関連記事と相談先

PoCが本番へ進まない構造そのものについてはAIエージェントのPoCから本番移行で扱っています。本記事はその直前段階、つまり本番へ出す当日までに埋める運用項目に絞っています。

本番化の判定に外部の視点を入れるならAI導入可否アセスメント、発注内容の詰めが残っているならAI開発・生成AI活用の発注前相談で扱います。既存システムとの接続が論点になっているケースはDX・システム開発の範囲です。

業務を「任せる・確認する・禁止する」に分ける

非エンジニア部門へAIを広げる場合も、製品単位ではなく業務単位で権限を決めます。

禁止事項だけでなく、任せてよい範囲と確認者を同じ行に置くと、現場が判断しやすくなります。

FAQ

Q1. 小規模な利用なら10問すべてに答える必要はありますか

規模の大小にかかわらず、10問はいずれも本番へ出す前に埋めることをおすすめします。特に2番（認証情報）、6番（費用の上限）、10番（停止手順）は、気づくのが遅れると被害が拡大しやすい項目です。

Q2. 費用の通知を設定していれば上限は不要ですか

通知と停止は別の機能です。原文によれば、支出上限を設定した場合でも到達率50%と80%の通知は出る一方、強制は即時ではなく推定コストに基づき、上限を超えた分は通常どおり課金されます。また、1つの上限が守るのは1つのプロジェクトの1つの対象サービスであり、アカウント全体を保護するものではありません。通知だけの設定になっていないか、そして上限が何を対象にしているかを確認してください。

Q3. クラウド事業者が異なる場合、同じ確認は必要ですか

必要です。用語や設定画面は異なりますが、鍵の管理、権限の担当、上限、停止という論点は共通です。

Q4. 現場が勝手に使い始めています。どうすればよいですか

禁止から入ると地下に潜ります。まず用途を申告してもらい、入力してよいデータの条件と上限を提示するほうが実効性があります。把握できていない利用の一覧を作ることが先です。

Q5. 10問を埋めるのに時間がかかりそうです

10問すべてに完璧な回答を用意する必要はありません。ただし、空欄のまま本番へ出すことは避けてください。時間が取れない場合は、本番へ出す範囲そのものを狭めるほうが安全です。利用者を限定する、扱うデータを絞る、機能を減らせば、各問に答えるための調査量が小さくなります。

参考情報

• Google Cloud Blog: 10 questions every startup should answer before moving to production with their AI prototype（2026年8月21日、Sergio Villani）
• GXO AI導入可否アセスメント
• GXO AI開発・生成AI活用 発注前相談

引用した失敗例および3段階の整理は、Google Cloudの公式ブログに記載されたものです。原文はスタートアップの開発者を対象とし、Google Cloudの製品構成を前提としています。本記事の10問はGXOが独自に組み直したもので、原文の10問と一対一で対応するものではありません。原文の設問そのものを確認する場合は、参考情報のリンクから原典を参照してください。