AIは使える。でも、現場で一番見てほしいコードは見せられない

この記事はZennにも同じような内容で投稿しています。
2026年6月時点での、自分の現場感を整理したものです。

AIを使えない現場を否定したいわけではなく、AIに慣れた自分にはこう見えている、という話として書いています。
委託開発や既存システム保守では、契約、機密保持、セキュリティポリシーを守ることが前提です。

はじめに

改めて感じることがあったので、以下のケースについての所感をまとめました。

状況は、こんな感じです。

• ドキュメントは皆無、コードが正
• 既存システムのコードをAIに投げられない
• プロジェクト全体をAIに読み込ませることもできない
• わからないところがあっても、コードをそのままコピーしてAIに聞くことができない

もちろん、理由はわかります。

委託開発や既存システムの保守では、顧客のコードや機密情報を外部サービスに出せないことがあります。
セキュリティや契約の都合を考えれば、それ自体は当然です。

ただ、実際にその環境に入ってみると、思った以上に開発の進みが悪い。

そこで気づいたのが、

自分は「AI前提で開発しよう」と意識していたわけではないけれど、
気づいたら、AIがある前提の開発スタイルになっていた

ということでした。

この記事は、AI活用のノウハウというより、AIに慣れたエンジニアが、AIにコードを見せられない現場で感じたギャップについてのメモです。

特に書きたいのは、「AIが使えないこと」そのものより、AIに一番見てほしい既存コードを見せられないことのもどかしさ です。

この記事で書きたいこと

この記事は、技術的にすごい解決策がある記事ではありません。

AIにコードを見せられない現場に入ってみて、自分の開発スタイルがいつの間にかAI前提に変わっていたことに気づいた、という話です。

書きたいことは、主に次のような内容です。

• AIにコードを見せられない現場で、開発の進みが悪くなった話
• 「AI前提で働いていたつもりはなかった」のに、気づいたら開発スタイルが変わっていた話
• SNSや動画サイトで見るAI開発と、委託開発・既存システム保守の現場感の違い
• AIを使えないわけではないけれど、一番見てほしいコードは見せられないもどかしさ
• その状況で、現実的にどう進めるか

どちらかというと、現場で感じた違和感を言語化した記事です。

AIにコードを見せられないと、調査の入口が重くなる

正直に言うと、進みが悪いです。

何かを修正しようとしても、まず既存コードを自分で追うところから始まります。

処理の入口を探して、呼び出し元をたどって、設定ファイルを見て、似たような実装を探して、命名から意図を推測する。

もちろん、これは昔からエンジニアが向き合ってきた作業です。

昔はそれが普通でしたし、今でも大事な作業です。

ただ、最近はこの最初の調査や整理を、かなりAIに助けてもらっていました。

例えば、今まではこんな感じで聞けました。

このプロジェクトの構成を説明して
この機能の処理フローを整理して
この修正を入れる場合の影響範囲を見て

するとAIが、完璧ではないにしても、最初の取っかかりを作ってくれます。

• どのファイルを見ればよさそうか
• どのクラスが関係していそうか
• 処理の流れがどうなっていそうか
• どこを触ると影響が出そうか

このあたりの見当をつけるのが、かなり楽になっていました。

それができないだけで、急に手探り感が強くなります。

高機能なIDEとAIアシスタントに慣れたあとで、急にテキストエディタだけで巨大な既存システムを改修しているような感覚です。

書けなくはない。
読めなくもない。
でも、かなり疲れる。

昔に戻ったというより、自分の普通が変わっていた

最初は「昔の開発に戻っただけかな」と思いました。

AIが出る前は、当然ですがAIにコードを読ませることはできませんでした。

知らない言語なら文法を調べる。
知らないフレームワークなら公式ドキュメントや既存コードを読む。
エラーが出たらログを見て、検索して、試して、また戻る。

それが普通でした。

ただ、今回の感覚は、単純に「昔に戻った」ともちょっと違います。

今は、コードそのものや機密情報を見せられなくても、AIをまったく使えないわけではありません。

例えば、一般論としては聞けます。

このフレームワークでは、一般的にどのファイルから処理を追うことが多いですか？

KotlinでUnresolved referenceが出る場合、よくある原因を教えてください

Spring BootでControllerからRepositoryまで処理を追うときの見方を教えてください

こういう聞き方なら、コードを見せなくても相談できます。

なので、完全にAI以前の世界に戻ったわけではありません。

ただ、プロジェクトの具体的なコードを読んでもらえないので、一番ほしいところには手が届かない。

AIは使える。
でも、いま一番見てほしいものは見せられない。

この状態が、なかなかもどかしいです。

そしてそこで初めて、自分の中での「普通の開発」が、いつの間にか変わっていたことに気づきました。

SNSで見るAI開発と、現場の距離感

SNSや動画サイトを見ていると、AI開発はかなり進んでいるように見えます。

「AIエージェントが自動で実装」
「プロジェクト全体を読ませてリファクタ」
「仕様を渡すだけでアプリ完成」
「もう人間はコードを書かない」

そういう話がどんどん流れてきます。

自分も、AIを使った開発の便利さはかなり実感しています。
なので、そういう話が全部大げさだとは思っていません。

ただ、その一方で、委託開発や既存システムの保守では、まだまだ別の現実があります。

• 顧客のコードを外部AIに投げられない
• プロジェクトファイルをAIに読み込ませられない
• セキュリティポリシー上、AI利用の申請が必要
• 申請してもすぐには通らない
• そもそも何をどこまでAIに渡してよいか決まっていない

こういう状況は、まだ普通にあります。

でも、この話はSNSではあまり目立ちにくいのだと思います。

派手なデモや成功例に比べると、制約のある現場での地味な苦労は、発信されにくいのかもしれません。

AIを使いにくい中で、既存コードを追って、仕様を確認して、調査して、修正して、レビューして、納期に追われている。

そういう現場感は、AI時代の開発を語るときに、もう少し表に出てもいいのではないかと思っています。

だから、表に出てくる情報と、現場の実感には少し差があるのだと思います。

AIに頼っていたというより、作業分担が変わっていた

ここで少し考えたのが、これは単に「AIに頼りすぎていた」という話なのか、ということです。

たしかに、そういう面はあります。

AIがあるから、細かいシンタックスを毎回暗記していなくても進められる。
知らないフレームワークでも、とりあえず取っかかりが作れる。
エラーも貼れば、原因候補を整理してくれる。

そういう便利さに慣れていたのは間違いありません。

ただ、自分の感覚としては、「AIに全部任せていた」というより、開発中の作業分担が自然に変わっていた、という方が近いです。

昔は、人間が全部読んで、全部整理して、全部調べていました。

今は、いつの間にかこんな分担になっていました。

• 調査の入口をAIに作ってもらう
• 既存コードの構造をAIに整理してもらう
• エラーの原因候補をAIに出してもらう
• 設計メモや調査メモのたたき台をAIに作ってもらう
• 自分は判断、確認、修正方針の決定に集中する

これを明確に意識していたわけではありません。

ただ、振り返ると、かなりそういう働き方になっていました。

なので、AIにコードを見せられない環境に入ると、今までAIが担当していた調査・整理・要約の部分も、全部自分でやる必要が出てきます。

これは、思ったより重いです。

つらいのは、コードを書く前の理解だった

AIにコードを見せられない現場で一番つらいのは、コードを書けないことではない気がしています。

もちろん、実装も大変です。
知らない文法やフレームワークの作法を自分で確認しないといけないので、時間はかかります。

でも、それ以上につらいのは、「既存コードを理解するまでの時間」が一気に増えることです。

新規開発なら、まだ自分で設計できます。
でも既存システムの場合、まず理解しないと触れません。

• この処理はどこから呼ばれているのか
• この設定値はどこで使われているのか
• このクラスは本当に必要なのか
• 似たような処理がなぜ複数あるのか
• この修正を入れるとどこに影響するのか

こういう調査は、AIがかなり得意な領域でした。

プロジェクト全体を読ませれば、

「このあたりが怪しいです」
「このファイル群が関係しています」
「この処理フローになっています」

という見取り図を作ってくれます。

その見取り図がない状態で、人間が巨大なコードの建物に入っていく。

これがなかなか大変です。

しかも、既存システムのコードは、必ずしもきれいとは限りません。

歴史もあります。
事情もあります。
コメントと実装がズレていることもあります。
なぜこうなっているのか、誰も覚えていないこともあります。

そういうコードを、AIに見せずに読む。

これはもう、普通に修行です。

コードを見せられない中でも、AIに相談できることはある

現状、AI利用の申請はしています。
ただ、すぐに許可が下りるとは限りません。

その間、どうするか。

完全な解決策ではありませんが、今できることはあると思っています。

まず、AIにコードを直接見せられないなら、自分で調査した内容を、抽象化してメモにしてみる。

例えば、こんな感じです。

画面Aの登録処理は、Controller X から Service Y を呼び、Repository Z でDB更新している。
ただし、入力チェックは別クラスに分かれている。

このように、具体的なコードを含めず、構造だけをメモする。

そのメモであれば、機密情報やコードそのものを含まない形にできる場合があります。
もちろん、会社や現場のルール確認はしておきたいところです。

また、AIに直接コードを投げられなくても、一般論として聞くことはできます。

Spring BootでControllerからService、Repositoryに処理が流れる一般的な構成を教えて

FlutterでViewModelからNotifierを呼ぶ設計の場合、どこを追えばよい？

KotlinでUnresolved referenceが出るときの確認ポイントを教えて

AIに「このコードを読んで」とは言えないけれど、「このタイプのコードを読むときの見方を教えて」とは言えます。

かなり不便ですが、完全にゼロではありません。

制約がある中でできることを整理すると、次のような感じです。

制約	できること
コードを貼れない	処理構造を抽象化して相談する
ファイル全体を読ませられない	自分で調査メモを作り、一般化して聞く
固有名詞を出せない	役割名に置き換える
エラー全文を出せない	エラー種別や発生条件だけを整理する
仕様を出せない	一般的な設計パターンや確認観点を聞く
AI利用申請待ち	自分用の見取り図・調査ログを貯める

あとは、AIに見せられない前提で、自分用の調査メモを増やしていく。

わかったことを少しずつ残していく。
この辺りはAI以前に戻っていますね...。

まぁ結局は、地味に一歩ずつやっていくしかないですね。

このあたりは、同じような現場にいる人も、たぶん自然にやっていることなんだろうと思っています。

AIを使える現場と、コードを見せられない現場では戦い方が違う

最近感じているのは、AI時代の開発現場には、すでに二つの距離感があるということです。

ひとつは、AIをかなり自然に使える現場。

プロジェクトを読み込ませて、設計を整理して、実装もテストもレビューもAIと一緒に進める。
人間は、指示、判断、確認、責任の部分を担う。

もうひとつは、AIを使いたくても、具体的なコードは見せられない現場。

セキュリティ、契約、機密情報、社内ルール、顧客ルール。
いろいろな事情で、AIにコードを見せられない。

どちらが正しい、という話ではありません。

顧客のコードや機密情報を守るのは当然です。
何でもAIに投げればいい、という話でもありません。

ただ、AIを使える現場と使いにくい現場では、開発速度も、調査の仕方も、エンジニアに求められる立ち回りも、かなり変わってきています。

AIを使える現場では、「どうAIに任せるか」が効いてくる。

AIにコードを見せられない現場では、「AIに見せられない中で、どう理解と調査を進めるか」が効いてくる。

同じエンジニアでも、戦い方がだいぶ違います。

まとめ：AIに何を見せられるかが、開発体験を大きく変える

今回の状況で一番感じているのは、自分ではそこまで意識していなかったけれど、開発スタイルはかなり変わっていたんだな、ということです。

AIがなかった時代は、コードを読んで、調べて、悩んで、少しずつ理解していくのが普通でした。

今でもそれは大事です。

ただ、AIを使うことで、開発の入口はかなり変わりました。

知らない言語でも取っかかりを作れる。
知らないフレームワークでも調査の方向が見える。
既存コードの全体像もつかみやすい。
設計資料や調査メモも作りやすい。

それを「AI前提で働いている」と意識していたわけではありません。

ただ、気づいたら、AIがある前提で調査し、整理し、実装方針を考えるようになっていました。

その状態で、

AIは使っていい。
でも、コードは見せられない。

となると、なかなか難しい。

AI時代の開発というと、派手なデモや自動実装の話が目立ちます。

でも実際の現場には、AIを使いたいのに、具体的なコードは見せられない。
AIで変わった開発スタイルと、現場のルールの間で悩む。

そういうケースも、まだまだあると思います。

AIがあると、コードを書く前の「理解する」「見取り図を作る」「影響範囲を考える」が大きく変わります。

だから、AIにコードを見せられない現場では、実装よりも前の段階で重さを感じます。

今回、自分はそこで初めて、自分の開発スタイルがすでにAI前提に変わっていたことに気づきました。

AIが使えるかどうかではなく、AIに何を見せられるか。

これが、これからの開発現場ではかなり大きな差になっていくのかもしれません。