※この記事は、2026年7月時点の自分のAI運用メモです。AIコーディングの安全性を保証する方法ではなく、非エンジニアの自分が何を確認すればよいかを考えた記録です。
最近は、AIに小さなツールや自動化の仕組みを作ってもらうことが増えました。
ここ数日の記事では、長時間処理の途中で現在地を見ることと、反復改善をどこで打ち切るかについて書きました。
どちらも、AIが動いている途中の話です。
今回は、その作業が終わった後、非エンジニアの自分が何を見て「このツールを使ってよい」と判断するかの話です。
以前なら自分では形にできなかったものが、会話しながら少しずつ動くようになる。
これはかなり便利です。
ただ、使えば使うほど気になることも出てきました。
完成する速度に、自分の理解が追いついていない。
AIがコードを書き、テストをして、「できました」と返してくる。
設計書や変更内容を説明してもらうこともできます。
それでも、非エンジニアの自分がコードを見て、内部で何が起きているのかを本当に理解できているかと言われると怪しいです。
かといって、分からないから全部使わないでは、AIコーディングを試す意味がなくなります。
最近は、全行を読めるようになることだけを目標にするより、受け入れる前の「検査工程」を持つ方が現実的なのではないかと考えています。
AIで作れることと、自分で分かることは別だった
AIにコードを書いてもらうと、自分では作れないものでも形になることがあります。
要望を伝える。
設計を考えてもらう。
実装してもらう。
エラーが出たら修正してもらう。
ここまでは、会話を続けることで意外と進みます。
問題は、その後です。
動いたから正しいのか。
別の場所を壊していないか。
想定していないデータを読んでいないか。
たまたま一つの条件だけで動いているのではないか。
後から問題が出た時に戻せるのか。
このあたりは、画面上で一度動いただけでは分かりません。
AIに聞けば説明は返ってきます。
ただ、その説明自体が正しいかを、自分がコードから確認できるとは限りません。
「AIがそう言っているから大丈夫」という状態になると、作ったというより、よく分からないものを受け取っただけになってしまいます。
仕様書を読んでも、コードの中身まで分かるとは限らない
これまで、AIに設計書や変更内容を残してもらうことは大事だと考えてきました。
実際、それがないよりはかなり助かります。
何を目的にした変更なのか。
どのファイルを触ったのか。
どんなテストをしたのか。
こうした記録があれば、後から作業を追いやすくなります。
ただ、ここで一つ勘違いしそうになりました。
設計書が読めることと、実装が設計書どおりになっていると確認できることは別です。
設計書には「このデータを読み、この処理をして、この結果を返す」と書いてある。
それを読めば、やりたいことは分かります。
でも、実際のコードが本当にその範囲だけを触っているかは、また別の確認になります。
非エンジニアの自分が、コードを一行ずつ読んで判断しようとしても限界があります。
だから、説明を増やすだけではなく、確認する場所を先に決める必要がありました。
製造現場でも、内部計算を全部追っているわけではない
この話を考えていて、製造現場の検査に少し似ていると思いました。
加工機が内部で行っている計算を、作業者が毎回すべて追っているわけではありません。
だからといって、機械が出したものを無条件で受け入れるわけでもない。
図面は合っているか。
材料は間違っていないか。
工程や順番はおかしくないか。
加工後の角度や寸法は基準に入っているか。
確認する場所があります。
内部の計算をすべて理解していなくても、入力、工程、出力を検査することで、少なくともそのまま次へ流してよいかは判断できます。
AIが書いたコードにも、これに近い考え方を持ち込めないかと思いました。
コードの全行を理解できないから何も判断できない、ではなく、自分が見るべき場所を決める。
それなら、分かったふりをせずに、止めるべきところでは止められます。
AI生成コードで確認したい七つの項目
今のところ、自分がAIへコード作成を頼む時に確認したいのは、次の七つです。
1. 何を直し、何をもって完了とするのか
最初に、作業の目的と完了条件を確認します。
「使いやすくする」「いい感じに直す」では、どこまで変えてよいのか分かりません。
何ができれば完了なのか。
逆に、今回は何を変えないのか。
ここが曖昧なままだと、テストが通っても目的どおりか判断できません。
2. 入力から出力まで、どう流れるのか
次に、何を読み、どこで処理し、何を返すのかを見ます。
コードそのものを読めなくても、データの流れなら確認しやすくなります。
入力していない情報を勝手に使っていないか。
外部へ送る必要のないデータを送っていないか。
出力先を間違えていないか。
処理の地図があるだけでも、見るべき場所がかなり絞れます。
3. どのファイルを、なぜ変更したのか
変更したファイルの一覧と、その理由も必要です。
頼んだ機能とは関係のない場所まで変わっていれば、いったん止めて確認できます。
変更量が想定より大きい時も同じです。
差分を全部理解できなくても、「なぜこのファイルまで触ったのか」は聞けます。
4. 何をテストし、何が通ったのか
「テストしました」だけではなく、何を試したのかを確認します。
正常な入力だけを試したのか。
空欄や異常な値も試したのか。
変更した機能だけでなく、既存機能も確認したのか。
テストが通ったという結果だけではなく、テストの範囲を見る必要があります。
5. 何が未確認なのか
ここは、かなり大事だと思っています。
AIが確認できなかったことを、確認済みのように扱わない。
外部サービスへ接続できなかった。
実際のデータでは試していない。
一部の環境だけで動作確認した。
こうした空白が分かれば、人間側で追加確認するか、今回は使わないかを決められます。
6. 既存機能やデータにどんな危険があるのか
新しい機能が動くかだけでなく、今あるものを壊さないかも見ます。
既存ファイルを書き換えるのか。
保存済みデータへ影響するのか。
外部通信や認証情報を扱うのか。
失敗した時の影響が大きい部分ほど、自分だけで受け入れず、確認の段階を増やす必要があります。
7. 問題が出た時に、どう戻すのか
最後は戻し方です。
変更前の状態が残っているか。
どの単位なら元に戻せるか。
戻した後に、どこを確認するか。
AIに実装を任せるなら、作り方だけでなく壊れた時の戻し方までセットで持っておきたいです。
「証拠を残す」だけでは、まだ半分だった
以前、AIエージェントの成果物には、説明より検証できる証拠を付けてほしいという記事を書きました。
その考え自体は今も変わっていません。
テスト結果、変更ファイル、参照した素材、未確認項目が残っていれば、成果物だけを渡されるより確認しやすくなります。
ただ、今回もう一段必要だと感じたのは、証拠を出してもらった後に、人間が何を見るかです。
大量のログや差分を渡されても、確認する側が見る場所を決めていなければ、結局「たぶん大丈夫」で終わります。
証拠を残すこと。
その証拠の中から、目的、流れ、変更範囲、テスト範囲、未確認事項、リスク、戻し方を見ること。
この二つがそろって、ようやく検査工程になるのだと思います。
検査工程があっても、専門家確認が不要になるわけではない
もちろん、この七項目を確認すれば、AIが書いたコードを安全に使えるという話ではありません。
自分で見つけられない問題は残ります。
テストが通っていても、設計そのものが間違っている可能性もあります。
特に、個人情報、決済、認証、外部公開、重要な業務データに関わるものは、非エンジニアの確認だけで進めるには危険です。
そういう領域では、エンジニアやセキュリティの専門家へ渡す必要があります。
ただ、その時にも検査工程は無駄になりません。
何を作ったのか。
どこを変えたのか。
何を確認し、何が分からないのか。
ここまで整理されていれば、専門家にも相談しやすくなります。
非エンジニアでも、受け入れるか止めるかは判断できる
AIコーディングを使っていると、自分もコードを全部読めなければいけないような気持ちになることがあります。
もちろん、少しずつ知識を付けることは必要です。
ただ、AIが作る速度に合わせて、すべてを短期間で理解するのは難しいです。
だからこそ、分かったふりをしないための検査工程が必要なのだと思います。
全行を読めない。
それでも、目的と違う変更なら止められる。
入力と出力がおかしければ止められる。
テスト範囲が狭ければ追加確認を頼める。
未確認事項が多ければ、そのまま使わないと決められる。
戻し方がなければ、先にバックアップを作れる。
AIを信じるか、信じないかの二択ではありません。
何を確認できたら受け入れるのかを、人間側が持っておく。
今の自分に必要なのは、コードを全部理解できているふりではなく、その判断を支える検査工程なのだと思います。
コメント