生成AIの導入では、従来型のシステム開発ほど初期費用がかからないように見える。

レッドハットの山下祐生氏

　一般的なシステム開発では、要件定義や設計、実装、テスト、インフラ構築、移行、教育などが必要になる。一方、生成AIは自然言語で指示でき、短期間で動く仕組みを用意しやすい。しかし、レッドハットの山下祐生氏（サービス事業本部コンサルティングサービス部、Associate Principal Consultant）は、AIを実業務で使い続けるためには、表面からは見えにくいコストがかかると指摘する。

　「生成AI利用に掛かるコストは、一見するとトークン利用料だけに見えるかもしれません。しかし実際に運用に入ると、コンテキストの整備やプロンプトの準備、出力のファクトチェック、機密データの取り扱い、権限管理や監査ログの収集など、さまざまな作業や仕組みが必要となるため、運用し続けるためのコストは決して安くありません」

生成AIの運用では、利用料だけでなく、入力の準備や出力の確認、権限管理、監査などにもコストがかかる（出典：山下氏の講演資料

　AIの出力を人が毎回確認する仕組みであれば、その確認作業も運用コストになる。機密情報を扱うなら、アクセス制御やログ管理も欠かせない。トークン利用料だけを見て導入費用を比較すると、こうした継続的な負担を見落とす恐れがある。

　山下氏によると、AIに任せる範囲を考える際は、コストに加えて「品質」と「正確性」も検討する必要がある。AIによって処理できるかどうかだけでなく、誤った場合に誰が検知し、どのように修正するのかまで設計することが、“PoC止まり”を回避する上で重要になる。

AIを「正解を出す担当者」にしてはいけない

　AIに任せる仕事の選び方を誤ると、業務品質を損ない、ビジネス上の責任を問われることもある。山下氏は、境界線の引き方を考える事例として、3社のケースを紹介した。

　1つ目は、スターバックスの在庫計数ツールだ。同社は、カメラと「LiDAR」（Light Detection and Ranging）を使って牛乳やシロップなどを数える仕組みを北米の店舗へ展開した。しかし、似た商品を取り違えたり、商品を数え漏らしたりする問題があり、2025年9月の展開から約9カ月後に利用を終了した。

　2つ目は、デロイト・オーストラリアがオーストラリア政府機関向けに作成した報告書だ。237ページに及ぶ報告書から、存在しない学術文献への参照や、裁判所の判断に関する誤った引用などが見つかった。修正版では「Azure OpenAI」を利用したことが開示され、同社は契約金の一部を返還することになった。

　3つ目は、エア・カナダのチャットbotによる誤案内だ。チャットbotは利用者に対して、航空券を購入した後でも慶弔運賃を申請できると案内した。しかし、実際の規定では搭乗後の申請は認められていなかった。

　山下氏は、これらの事例に共通する問題を次のように説明する。

　「これらの失敗事例に共通しているのは、AIを事実や数値、規定といった『正解そのものを出す担い手』にしてしまった点です。AIは意味付けや解釈、要約といった文脈の理解は得意ですが、正解を保証することはできません。従って正解を導き出すためのプロセスには、必ずシステムや人による承認ゲートを設置する必要があります」

　もっともらしい回答を生成できることと、正確な回答を保証できることは同じではない。誤りが許容できない領域までAIだけに任せるのではなく、正確性を確保するシステムや、最終的に責任を負う人を処理の中に組み込む必要がある。

「考えるAI」「正確に動かすシステム」「責任を負う人」

　では、人・生成AI・システムには、それぞれ何を任せればよいのか。山下氏は、最終判断や承認は人、解釈や要約といった非定型処理は生成AI、正確で反復的な実行はシステムやスクリプトが担うという役割分担を示す。

最終判断や承認は人、解釈や要約は生成AI、正確で反復的な実行はシステムやスクリプトが担う（出典：山下氏の講演資料）

　AIエージェントにスクリプトを生成させ、APIを呼び出すこともできる。しかし、同じ処理を繰り返し正確に実行する必要があるなら、従来通りシステムやスクリプトとして実装した方が、再現性や監査性を確保しやすい。一方、従来のシステムでは処理しにくかった曖昧な指示の解釈や、非構造化データの整理、文章化といった仕事は生成AIが担える。人は定型作業から離れ、判断やアーキテクチャ設計、業務改善に時間を使えるようになる。

　「生成AIは、これまで『人とシステムの境界』に位置していた曖昧な業務や非定型な業務を、かなり肩代わりしてくれるようになりました。一方で、最終的な判断や信頼できるデータの取り扱い、監査といった部分は、これまで通り人とシステムに残しておくのが、あるべき本来の姿だと考えています」（山下氏）

　生成AIが得意なのは、意味付けや解釈、言語化など、答えが一つに定まらない領域だ。反対に、同じ入力に対して同じ結果を返すこと、最新データを漏れなく処理すること、厳密な数値を保証することは苦手とする。

生成AIは曖昧な指示の解釈や要約を得意とする一方、再現性や正確性、最終判断を苦手とする（出典：山下氏の講演資料）

　こうした生成AIの特性を踏まえ、単に「AIで実現できるか」ではなく、求められる正確性や再現性、失敗した場合の影響を基に担い手を選ぶことが、境界線を引く基準となる。

プロトタイプはAIに広く任せ、本番運用で境界線を引き直す

　人とAI、システムの役割分担は、開発から運用まで固定するものではない。山下氏によると、生成AIが特に力を発揮するのは、最初に動くものを作るPoCの段階だ。

　「生成AIが本当に強いのは、最初の動くモノを作るフェーズです。生成AIはプロトタイプを作ることに極めて向いており、『ユーザーのニーズが本当にあるのか』『ユーザーが使ってみて本当に便利なのか』といった点を短期間のうちに確かめるPoCでの活用に極めて適しています」（山下氏）

　PoCでは、まずAIに広い範囲を任せて仕組みを動かし、利用者のニーズを確かめる。生成AIの速さと柔軟性を生かしてプロトタイプを短期間で開発できることは、山下氏が生成AIの得意領域として挙げる点だ。

　一方、本番運用へ移行する際には、正確性や再現性、責任の所在などを踏まえて、人と生成AI、システムの役割分担を見直す必要がある。ただし、これは生成AIに仕事を任せること自体を避けたり、本番運用から生成AIを外したりするという意味ではない。解釈や要約など、生成AIが得意な処理は引き続き任せながら、正確で反復的な処理はシステムへ、責任を伴う判断や承認は人へ再配置する。運用を始めた後も、それぞれの得意領域を見極めながら境界線を再設計していくことが重要になる。

　山下氏は、その境界線を見直す方法として「観る・決める・動かす・続ける」というフィードバックループを挙げる。さらに、このループを「観察」「候補抽出」「判断」「設計」「移行」「再評価・廃止」の6ステップに分けている。

利用実態を観察し、システム化する処理を選び、段階的な移行と再評価を繰り返す（出典：山下氏の講演資料）

　まず運用データから利用実態を把握し、正確性や影響の大きさなどを基に、システム化する価値がある処理を抽出する。その上で、AIへ任せるのか、人の確認を挟むのか、システム化するのかを判断する。

　移行は一度に実施せず、問題があれば元に戻せるよう段階的に進める。移行後も利用状況やコストを確認し、必要に応じて役割分担を見直す。使われなくなった処理や、コストに見合わなくなった処理は廃止する。

　「こうしてAIでまずは高速に始めて、システムで固めて、最終的に人が責任を持てる形に設計していくことで、より生成AIを上手に使っていけるのではないかと考えています」（山下氏）

　PoCで素早く試せることは、生成AIの大きな利点だ。ただし、そこで決めた役割分担を本番運用まで持ち込む必要はない。生成AIが得意な処理は引き続き任せながら、正確性や再現性、責任の所在に応じて、人と生成AI、システムの役割を組み替える。運用後も境界線を見直し続けることが、AI活用をPoCで終わらせないための条件となる。