AIを使った開発フロー、顧客にどこまで説明する？

「AIも使っています」と言う前に、少し迷う

「これ、どこまで言った方が安心なんだろう…」

提案や面談で、AIを使った開発フローについて聞かれた時、少し言葉に詰まることはありませんか？ 隠したいわけではない。むしろ、効率よく進められることは伝えたい。でも、言い方を間違えると「じゃあ品質は大丈夫ですか」「うちの情報をAIに入れるんですか」と、不安の方が先に立ってしまう。

この感覚は、かなり自然です。Stack Overflow の 2025 Developer Survey では、回答者の84%が開発プロセスでAIツールを使っている、または近く使う予定だとされています。一方で、AI出力の正確性については、信頼する回答より不信を持つ回答の方が多い結果でした。つまり、AI利用は広がっているのに、「AIが出したから安心」とは見られていません。

だから、顧客に必要なのは「使っています」「使っていません」の一言だけではありません。どの工程で使い、どの情報は入れず、どこを人間が確認し、最終責任をどう扱うのか。 ここまで見えると、AI利用は不安材料ではなく、進め方の透明性になります。

この記事では、AIを使った開発フローを、秘密情報、品質確認、レビュー責任、提案時の言い方に分けて整理します。AIを誇る話ではなく、相手が安心して任せられる説明順の話です。

顧客が聞きたいのは、ツール名より「境界線」

AIの話になると、ついツール名やモデル名から説明したくなります。「このAIを使います」「コード生成にこのツールを使っています」と言う方が、技術的には具体的に聞こえるからです。

ただ、発注側が最初に知りたいのは、たいていそこではありません。顧客が気にしているのは、自社の情報が外へ出ないか、成果物の品質が落ちないか、問題が起きた時に誰が確認するのかです。ツール名だけを詳しく話しても、この不安にはあまり届きません。

まずは、入力する情報の線を引く

最初に説明したいのは、AIに何を入力し、何を入力しないかです。ここが曖昧なまま「AIを使います」と言うと、顧客は自分たちの仕様書、顧客データ、契約情報、未公開の事業計画まで外部サービスへ入るのではないかと想像します。

実際には、AIを使う場面にも段階があります。一般的な技術調査、実装方針の比較、テスト観点の洗い出しのように、機密情報を入れずに使える場面もあります。一方で、本番データ、個人情報、認証情報、未公開の業務ルール、契約条件をそのまま外部AIに入れるのは避けるべき場面です。

AI事業者ガイドラインは、AI活用に伴うリスクをライフサイクル全体で認識し、必要な対策を自主的に実行する考え方を示しています。個人の提案でも同じで、「便利だから使う」ではなく、情報の扱いを先に切ることが信用につながります。AI利用の説明は、何を入れるかより先に、何を入れないかを言うと安心されやすい。

次に、使う工程と使わない工程を分ける

次に説明したいのは、どの工程でAIを使うかです。AI活用を一枚で語ると、「全部AI任せなのかな」と受け取られやすくなります。そうではなく、初稿、比較案、観点出し、コード補助、ドキュメント整理など、使う場所を分けて話す方が伝わります。

たとえば、「実装のたたき台やテスト観点の洗い出しにはAIを使います。ただし、要件判断、既存仕様との照合、セキュリティ影響、最終レビューは人間が見ます」と言う。これだけで、AIを使うこと自体より、コントロールの所在が見えます。

OWASP の LLM Top 10 for 2025 では、プロンプトインジェクション、機密情報の漏えい、不十分な出力検証、過剰な自律性などがLLMアプリケーションのリスクとして整理されています。開発支援としてAIを使う場合も、同じ発想で「出力をそのまま信用しない」「権限や実行範囲を広げすぎない」ことを説明できると、技術者としての見方が伝わります。

「速くできます」だけだと、不安が残る

AIを使うメリットとして、スピードは確かに分かりやすいです。調査が早い、初稿が早い、比較案が早い。相手にとっても魅力があります。

でも、速さだけを前面に出すと、品質の説明が抜けます。「早いのは分かりました。では、その結果は誰が確認するんですか？」という問いが残る。ここを先回りして説明できると、AI活用はかなり受け入れられやすくなります。

AI出力は、成果物ではなく「材料」として扱う

実務では、AIが出したものをそのまま成果物にするより、材料として扱う方が安全です。調査メモなら、一次情報へ戻す。コードなら、既存設計、テスト、認可、エラー処理、保守性を見る。提案文なら、誇張表現や事実関係を確認する。

NIST の AI RMF Generative AI Profile は、生成AIのリスクを設計、開発、運用などの段階で管理するための資料です。そこでは、生成AI固有または増幅されるリスクを把握し、目的や優先度に合わせて管理する視点が示されています。ValueGateの読者に引き寄せるなら、「AIで出した材料を、どの観点で成果物へ変えるか」を説明することが大事です。

顧客へは、こう言うと伝わりやすいです。

• AIは、初稿・比較案・観点出しに使います
• 顧客情報や本番データは、許可なく入力しません
• 生成された内容は、既存仕様、セキュリティ、テスト観点で人間が確認します
• 最終的な提出物は、担当者がレビューしたものとして扱います

これは長い規約ではありません。面談や提案書に入れるなら、数行で十分です。大事なのは、「AIを使います」の後に、相手が心配する順番で答えることです。

レビュー責任を曖昧にしない

AIを使う開発で一番揉めやすいのは、うまくいった時ではなく、問題が出た時です。「AIが出したから仕方ない」という言い方は、顧客から見るとかなり不安です。仕事として受ける以上、AIを使ったかどうかとは別に、確認して渡す責任は残ります。

もちろん、すべてのリスクを一人で背負うという意味ではありません。仕様未確定の部分、顧客側の判断が必要な部分、追加調査が必要な部分は、きちんと分けて戻す必要があります。ただし、AI出力を採用するかどうかの判断を、AIのせいにしないことは大切です。

METR の 2025年の実験では、経験あるオープンソース開発者がAIを使った時、体感では速くなったと思っていた一方で、実測では遅くなったケースが報告されました。この結果をそのまま全現場へ当てはめる必要はありません。ただ、「速く感じる」と「実際に品質を保って届けられる」は別の問いです。顧客説明でも、ここを混ぜない方が信頼されます。

提案時は、安心材料から順番に出す

AI活用を説明する時、全部を細かく話す必要はありません。むしろ、最初から長い説明にすると、相手はどこを見ればいいか分からなくなります。必要なのは、相手の不安に近い順番で短く出すことです。

おすすめは、4つの順番です。入力しない情報。使う工程。人間が確認する観点。判断が必要な場合の戻し方。この順で話すと、AIの便利さより先に、安心材料が伝わります。

「隠す」でも「誇る」でもなく、運用として話す

AIを使っていることを隠すと、後から分かった時に不信感が出ます。一方で、AI活用を過剰に誇ると、相手は「便利そうだけど、うちの業務をちゃんと見てくれるのかな」と感じます。

ちょうどよいのは、運用として話すことです。

開発の初稿作成や観点整理にはAIを使います。ただし、顧客固有の機密情報や本番データは許可なく入力しません。出力内容は、既存仕様・セキュリティ・テスト観点を人間が確認してから提出します。

このくらいで十分な場面は多いです。相手が詳しく知りたい場合は、そこから利用ツール、データ保持設定、社内ルール、レビュー手順へ進めばいい。最初から全部を説明しようとしなくて構いません。

判断が必要な場所は、先に戻すと言う

顧客説明で抜けやすいのが、「判断が必要な場合は戻します」という一文です。AIを使うと、何でも勝手に進められるように見えます。でも実際には、業務判断、契約判断、公開範囲、個人情報の扱い、価格や責任範囲の線引きは、勝手に決めてはいけません。

ここを先に言えると、相手は安心します。

• 顧客固有の業務判断が必要な場合は、仮置きせず確認します
• 契約や権利に関わる判断は、技術判断として処理しません
• 本番影響がある変更は、AI出力の有無に関係なくレビュー対象にします
• 不確かな情報は、出典確認または顧客確認を挟みます

防御的に聞こえるかもしれません。でも実際には、前に進めるための説明です。勝手に決めない場所が見えているからこそ、任せられる範囲も広がります。

小さな案件ほど、説明テンプレを持っておく

AI利用の説明は、大企業のAIポリシーだけの話ではありません。むしろ、個人受託、業務委託、副業、小さな改善案件ほど効きます。契約書や運用ルールが細かく整っていない分、最初の説明がそのまま信頼になります。

毎回ゼロから考えると重いので、自分用の短いテンプレを持っておくと楽です。提案書、見積り、初回面談、作業開始時に使える形で十分です。

まずは4行だけでいい

たとえば、最初はこの4行で足ります。

• AIは、調査、初稿作成、比較案、テスト観点の洗い出しに使うことがあります
• 顧客固有の機密情報、本番データ、認証情報は、許可なくAIへ入力しません
• AI出力はそのまま納品せず、既存仕様、品質、セキュリティ、事実関係を確認します
• 業務判断、契約判断、公開可否などは、必要に応じて顧客確認を挟みます

これだけでも、「AIを使う人」ではなく、「AIを使う前提で安全に進める人」として見え方が変わります。説明があるだけで、相手は質問しやすくなりますし、自分も作業範囲を守りやすくなります。

記録に残すと、価格にもつながる

この説明は、単なる安心材料だけではありません。価格や役割の説明にもつながります。AIを使って初稿を早く出すだけなら、時短として見られます。でも、情報管理、レビュー観点、判断の戻し方まで含めているなら、それは進行設計や品質保証の一部です。

週報や納品メモにも、少し残しておくとよいです。「AIで生成した案をもとに、既存仕様との齟齬、権限、エラー時の動き、テスト観点を確認しました」と書くだけで、裏側の仕事が見えます。AI利用を説明できる人は、単に速い人ではなく、安心して任せられる進め方を設計できる人です。

AIを使うかどうかを、過剰に特別扱いする必要はありません。ただ、相手の情報と成果物を預かる以上、使い方の線引きは言葉にした方がいい。そこまで含めて説明できると、AI活用は不安ではなく、信頼を作る材料になります。

最後に

AIを使った開発フローを顧客に説明する時、完璧なAIポリシーを作る必要はありません。最初から法務文書のように固くしなくても大丈夫です。

ただ、「AIも使えます」「早くできます」だけでは、相手の不安は残ります。顧客が知りたいのは、どの情報を入れないか、どの工程で使うか、誰が確認するか、勝手に決めない場所はどこかです。

まずは次の提案や面談で、4行だけ足してみてください。入力しない情報、使う工程、人間レビュー、顧客確認が必要な判断。この4つがあるだけで、AI活用の見え方はかなり変わります。

AIを隠さなくていいし、過剰に誇らなくてもいいです。安心して任せてもらうために、使い方の境界線を先に見せる。そこから、AI時代の提案は少しずつ強くなります✨

参考にした情報

• Stack Overflow「2025 Developer Survey: Artificial intelligence」（2025年版、2026年7月6日確認）
• Google Cloud / DORA「State of AI-assisted Software Development 2025」（2025年版、2026年7月6日確認）
• NIST「AI Risk Management Framework」（2023年1月26日公開、2026年7月6日確認）
• NIST「AI RMF Generative AI Profile」（2024年7月公開、2026年7月6日確認）
• OWASP「Top 10 for LLM Applications 2025」（2025年版、2026年7月6日確認）
• 総務省・経済産業省「AI事業者ガイドライン（第1.0版）」（2024年4月19日公開、2026年7月6日確認）
• METR「Measuring the Impact of Early-2025 AI on Experienced Open-Source Developer Productivity」（2025年7月10日公開、2026年2月24日更新、2026年7月6日確認）