AI丸投げ時代は来ない【Part2】──既存プロジェクトでAIが破綻する理由～守りのAI活用～7割の準備が現場を救う

大変長らくお待たせいたしました。
当アカウントをnoteで開設した一発目の記事から約1か月、AI小説を書いたり簡単アプリ作成記事を書いたりと寄り道をしましたが、続編に参りましょう！！

Part1をまだ見ていない！という方はこちらから

さらに番外編も先に目を通してもらえるとこのPart2がさらに深みを増します。

初回に提示した「7割人間・3割AI」──
今回はその"7割"が、現場で具体的に何をするのかを明かします。

◆ はじめに──僕が危うく踏みかけた"地雷"

AIにコードを貼り付けて相談する。

エンジニアなら一度はやりかける行為です。

僕自身、プログラミング学習中に「これが実務コードだったら危なかったな」とゾッとした瞬間がありました。
それくらい、AIに丸投げしたくなる誘惑は強い。

そしてこれは、僕だけの話ではありません。

今のWeb業界全体で、静かに、でも確実に広がっているリスクです。

◆ なぜ既存プロジェクトが"地雷原"になるのか

特にフロントエンドやWebデザインの領域は、非エンジニア出身の人が多い。デザインから入ったり、副業から入ったり、スクールから入ったり。

そういう環境では──

「実務コードをそのまま貼るのが危険」という感覚が育つ前に、"貼れば解決する快感"だけが先に来てしまう。

これは誰が悪いわけでもなく、構造的にそうなりやすいだけです。

エンジニア経験があってそれなりのセキュリティ教育を受けてきた僕ですら危うかったので。

ただ、無理もないんです。
当時の既存プロジェクトに参画中、その現場でAIは使用禁止だったんです。ですから、生成AIに対するガイドラインがまだ定まっていない状態だったんです。

あまりに急速なAIの普及に、企業も追いついていないのです。

実務コードには、こうした情報が詰まっています。

• 顧客情報

• 内部APIのURL

• 認証トークン

• DB情報

• 社内の命名規則

• プロジェクト固有の仕様

これらは"会社の資産そのもの"です。

これは僕がたまたま「実務でAIを使用する前に自宅でプログラミング学習をしていたから気づけた」のであって、運が良かっただけかもしれません。

もし深く考えずに貼っていたら──情報漏洩のリスクを、自分の手で作り出すところでした。

◆ コードをそのままAIに渡すと何が起きるのか

① コードは「機密情報の塊」

コードには、外部に出した瞬間に問題になる情報が大量に含まれています。

顧客ID、メールアドレス、社内コード、内部APIのURL、認証情報、ビジネスロジックの核心──

AIはこれを「ただのテキスト」として扱いますが、企業にとっては**"漏洩したら終わる情報"**です。

② AIは"意図"を理解しない

既存プロジェクトのコードをAIに渡すと、こう動きます。

• 「この方が綺麗」と勝手にリファクタリング（内部構造をきれいに整理・改善する）

• 命名規則を独自解釈して変更

• 既存仕様を"改善"したつもりで挙動を変える

• 影響範囲を理解せずに別の箇所を壊す

AIは「意図」より「整合性」を優先します。
その結果──動くけど壊れているコードが生まれます。

③ 文脈を誤解する

既存プロジェクトには「なぜこの実装なのか？」という背景が必ずあります。

過去のバグ対応、特定顧客の要望、他システムとの制約、チームの歴史的判断──

AIはこれらを読み取れません。
その結果、正しく見えるけど前提を壊す修正を平気で出してきます。

その結果、ある修正をすることで別の正常だった機能に不具合が生じる。
現場ではこれを「デグレ」と呼びます。
──直したはずなのに、別の場所が壊れている。

これに気づかない場合、新たな不具合を仕込んだままリリースしてしまうということなんです。

その恐怖を、現場の人間なら一度は味わっているはずです。

④ 手戻りが爆発的に増える

AIに任せたら早くなるはずなのに、逆に時間が溶けていく。

修正箇所の意図確認、影響範囲の再チェック、AIが壊した部分の復旧、追加でAIに説明し直す、結局自分で書き直す──

これがAI丸投げの隠れコストです。

◆ 破綻の本質──AIは"意図"も"責任"も理解しない

既存プロジェクトで破綻が起きる理由は明確です。

AIは歴史を知らない。背景を理解しない。
前提条件を推測しない。責任を取らない。

AIの指示理解は確かに異常に早い。
ただしそれは、A・B・C・Dと複数の指示を「もっともらしくこなす」速さです。

人間側の「本当はこういうことをして
もらいたい」という目的・意図は、完璧には理解できません。

なぜなら、その企業・プロジェクトの理念・方針・設計思想を、AIは知らないからです。

だからこそ、既存プロジェクトはAI丸投げ禁止の地雷領域なのです。

◆ では、どうすればいいのか──安全にAIへ渡すための"実務テンプレ"

ここからは具体的な方法です。
①〜⑤の順番で進めることで、安全かつ高精度にAIを活用できます。

① まずは「エラーログ」から渡す

不具合調査の第一歩は、
いつだってエラーログです。

コードを一行も見せずに、ログだけで
AIが原因を特定してくれることも実際にあります。

ただしログには個人情報が紛れ込んでいる
ことがある。ここは必ずマスキングします。
ただしログには個人情報が含まれることがあります。
ここは必ずマスキングします。

customerId=12345   →   customerId=XXXXX
email=foo@example.com   →   email=masked@example.com

ログの"構造"だけ残せばAIは十分理解できます。

② デバッグが必要な場合は「候補メソッド」を抽象化して渡す

ログだけでは原因が分からず、コードを追う必要があるケースも多い。
でもコードをそのまま渡すのは危険です。

やるべきはこれです。

1. 怪しいメソッドを3〜5個ピックアップ

2. メソッド名を抽象化

3. 中身も"構造だけ"残して抽象化

例：

public int calculateAmount(InputData data) {
    var base = getBaseValue(data.type);
    var discount = getDiscount(data.userRank);
    return base - discount;
}

これなら個人情報も機密情報も含まれません。

③ データは「意味を持つ名称」を必ずマスキングする

DBから抜いたデータをそのまま渡すのは絶対NGです。
顧客名、住所、メール、商品名、プラン名──
こうした"意味を持つ文字列"はすべてマスキングします。

数値は基本的にOKですが、意味を持つコード
（例：プランID）はIDごと抽象化します。

planId=101   →   planId=A
planId=102   →   planId=B

④ AIへの指示は「意図」を明確にする

AIは意図を理解しません。
だから意図を"文章で"渡す必要があります。

インプットのデータは○○○○で、
この処理を通すと□□□という結果になります。
しかし期待値は△△△△です。
原因となり得る箇所はどこですか？

これだけで、AIは十分に推論できます。

⑤ ここまで準備すれば、AIは"意味を汲んで"分析してくれる

抽象化した材料だけで、AIはデータの流れ、値の変化、怪しいメソッド、破綻している処理──これらを十分に分析できます。

「安全に抽象化した材料」だけで、AIは十分に役に立ちます。

これが、AIを"従える"ための実務的な方法です。

◆ まとめ──AIに渡すのは「構造」と「意図」だけで十分

今回伝えたかったことはこれだけです。

やることはシンプルです。
コードそのものは渡さない。情報はマスキングする。
構造だけ残す。意図を言葉にする。

──たったこれだけで、あなたのAIは"暴走する部下"から"信頼できる相棒"に変わります。

◆ 次回予告

既存プロジェクトは"守り"の戦場でした。

しかし、新規プロジェクトはまったく別の世界になります。

次回は──
AI前提で新規プロジェクトを設計すると何が変わるのか、AIを最大限活かすための"最初の設計"とは何か、ここを深掘りしていきます。
何を作るかより、なぜ作るかを言語化する力。AIに渡すための目的の設計力。この力があるかどうかで、新規プロジェクトの行方は大きく変わります。

既存は守り、新規は攻め。

AIが最も輝く瞬間が、次回から始まります。

次回
AI丸投げ時代は来ない【Part3】──新規プロジェクトはAIが最も輝く～攻めのAI活用・前編～