ITコンサルタントに聞く、AIが勝手に置く前提と検証の順番
〜AIは、権限もネットワークもバージョンも黙って前提にしている〜
「このコードで動きますか」と生成AIに尋ねると、たいていは動きそうなコードが返ってきます。ですがその回答は、あなたが使っているクラウドの権限も、社内ネットワークの状態も、製品のバージョンも聞かないまま書かれています。ERPやCRMといった業務システムの導入を支援するITコンサルタント・青井真吾氏は、AIを日常業務に組み込みながら、AIが勝手に置いた前提こそが誤りの入口になると話します。
生成AIの技術的な回答は、どこまで、どうやって確かめればよいのか。この記事で伺ったのは、AIに任せてよい場面の見分け方、AIが黙って置いていく前提、そして情報を確認する順番の3つです。個人が手元でツールを作るときにも、会社がシステムを入れるときにも使える判断の順序として聞きました。
青井真吾
AOIS Consulting株式会社 代表取締役。青井 真吾（あおい しんご）。大学卒業後はIT企業に入社。システムエンジニアとして大手企業向けのERPシステム開発を経験。その後独立し、人材派遣、不動産、自動車、ファッション、エネルギーなど多くの業界でDX推進などのITプロジェクトに従事。現在はAOIS Consulting株式会社を設立し、エンタープライズシステムの開発・導入を支援するITコンサルティングサービスを展開している。
「インプットを渡せて、具体的な指示が出せるか」——AIに任せる場面を分ける2つの条件
青井氏は、AIを遠ざけている専門家ではありません。ERP（会計や人事、販売、在庫といった基幹業務をまとめて扱う業務システム）やCRM（顧客との取引履歴を管理するシステム）の導入を支援する立場で、日常的にAIを使っています。議事録の作成、業務フローの作成、社内のディスカッションペーパー、クライアントへの説明資料。膨大な資料の要約や、数字をグラフに見える化する作業も任せています。
ただし、どんな場面でも使うわけではありません。使う場面と使わない場面を分けているのは、2つの条件でした。
裏返せば、この2つが欠けたときにAIは嘘を混ぜる、という整理です。手元に渡せる材料がないまま尋ねれば、AIは知らない部分を自分で埋めて答えます。青井氏が「あえて使わない業務」と呼ぶのは、業務の種類ではなく、この条件が揃わない状態のことです。
コードを書かせるときにも、同じ条件が効いてきます。
「ウェブシステムを作って」は、インプットも指示も足りていない依頼です。「ウェブシステムにアクセスするためのAPI（外部のシステムとデータをやりとりするための窓口）のサンプルコードを書いて」まで細分化すると、AIが勝手に埋める余地が小さくなります。AIに全体を作らせるのではなく、部品を作らせて組み立てるのは自分、という分け方です。
AIに投げる前の確認は、次の2つです。
- ・インプットとして渡せる材料が手元にあるか（既存の資料、ログ、いま動いているコード）
- ・出したいものを、具体的な指示に分解できているか（「システムを作って」ではなく「この処理のサンプルコードを書いて」）
AIが黙って置いていく前提——権限、通信、そして「最新バージョン」
2つの条件のうち、実務で崩れやすいのは前提のほうです。人間が相手なら「その話、どの環境の前提ですか」と聞き返してもらえますが、AIは聞き返さずに、自分で前提を置いたまま答えます。しかもその前提は、回答の中に書かれていません。
権限の話は、手順どおりに進めたのに途中で止まる、という形で表に出ます。回答そのものは間違っていないのに、自分の環境では実行できません。通信の前提も同じです。
もっとも身近な例は、製品のバージョンです。
表計算ソフトの関数ひとつでこれが起きるのですから、OSやミドルウェア、クラウドサービスの設定画面ではもっと起きます。しかもやっかいなのは、返ってきた回答が文章として整っていることです。自分の環境で試すまで、間違いは表に出てきません。
対処は、前提を先に書いてしまうことです。青井氏は「前提は正確かつ具体的に置いたほうが、品質の高い回答が返ってくる」と話します。質問文に添えたいのは、次のあたりです。
- ・製品名とバージョン（OS、ミドルウェア、表計算ソフトまで）
- ・設定変更の権限が、自分にどこまであるか
- ・ネットワークの状態と、通信上の制約
- ・クラウド構成のうち、こちらでは変更できない部分
ざっくり、正確に、そして検証する——技術情報を確かめる順番
前提を整えても、返ってきた回答をそのまま信じてよいことにはなりません。青井氏は、自分がよく知っている領域と、そうでない領域とで、AIとの付き合い方を分けています。よく知っているものについては「念のためAIにも聞いてみる」という裏付けの取り方をしますが、「新しいものを調べているときは、基本的に信じることはなくて、必ず裏付けを、その情報の確からしさを自分で調べるようにしています」。
では、危ない回答には見分けのつくサインがあるのでしょうか。返ってきたのは、期待した答えではありませんでした。
サインを覚えて見分けるのではなく、確かめます。裏を返せば、見分けられるつもりでいることのほうが危ない、という立場です。青井氏が実際にたどる確認の順番は、はっきりしています。
- ・ベンダーの情報で概要をつかむ（読みやすく、まだ検討している段階に向いている）
- ・公式ドキュメントとリリースノートで、仕様を正確に確認する
- ・検証環境で再現テストをして、自分の環境で動くことを確かめる
- 製品の更新内容を、バージョンごとに記した公式の文書です。新しく追加された機能、修正された不具合、仕様が変わった箇所などが書かれています。
この順番は、調べている側の状況に対応しています。ある製品を調べているのは、たいてい導入を検討している最中です。その段階で詳細な仕様書に潜っても、判断に必要な全体像はつかめません。だから概要から入り、使うと決めたところで仕様に踏み込み、最後に自分の環境で動かして確かめます。AIの回答は、この流れのどれかの代わりに置けるものではありません。
「動く」と「安全に運用できる」の間にあるもの
生成AIにコードを書かせ、社内の便利ツールを自分たちで作る動きが広がっています。ただ、動いた時点で完成としてよいのか。青井氏の答えは、はっきりしています。
続けて、2つの言葉の意味を切り分けます。「動くことは、多分システムエラーが起きないことという意図だと思うんです。安全に動くのは、システムエラーにならないことじゃなくて、想定通りの結果が返ってくることを確認している状態だと思うので」。エラーが出ないことと、想定した結果が返ってくることは別だ、という整理です。
把握していないコードには、もう1つのリスクがあります。青井氏は、AIが書いたコードを中身を見ないまま使う場合について、「外部のサーバーに実はデータを送っているというソースコードが書かれている可能性は、ゼロじゃない」と話します。社内の便利ツールのつもりでも、扱っているのが顧客のデータであれば、影響は社内で収まりません。
では、本番に出す前の共通チェックリストは作れるのでしょうか。AIに頼めるのは議事録、コード、資料、情報の抽出とさまざまで、「それぞれチェック項目が違うと思うので、一般的なものはないと思っています」。項目を借りてくるのではなく、自分が作らせたものに合わせて決めるしかない、ということです。
そのうえで、任せてよいかどうかの境界線が引かれます。
境界線は、AIの性能側ではなく、使う側の検証能力の側に引かれています。同じ作業でも、読める人には任せてよい仕事で、読めない人には任せてはいけない仕事になります。本番の前に、少なくとも次の3つは自分に問えます。
- ・出てきたものを全部読んで、構造を把握できているか
- ・エラーが出ないことではなく、想定通りの結果が返ることを確認したか
- ・自分が意図していない外部との通信が、混ざっていないか
青井氏の話に一貫していたのは、AIの精度を見抜こうとするのではなく、自分が確かめられる大きさまで問題を小さくする、という考え方でした。前提を具体的に置き、インプットを渡し、タスクを細分化します。それでも返ってきたものは、ベンダー情報、公式ドキュメント、検証環境の順で確かめます。任せてよいかどうかを決めるのはAIの出来ではなく、自分がチェックできるかどうかです。
なお、企業が業務システムにAIを組み込むときに何が起きるのか——期待値がどこでずれるのか、PoCをどう使うのか、社内文書を参照させても嘘が減らないのはなぜか——については、別記事「「AIの完成度は7割8割」ITコンサル会社代表が語るAI導入の落とし穴」で青井氏に伺っています。
取材日：2026年8月19日
この記事を書いた人
編集プロダクション雨輝
2014年創業。取材・執筆、編集、校正・校閲、ファクトチェックなど、コンテンツ制作を幅広く手がける編集プロダクション。正確性と信頼性を重視し、専門家への取材や一次情報の確認を通じた、質の高い情報発信に取り組んでいる。https://amaterupro.jp/
