開発フォルダが356MBになっていました。最初は20MBでした。整理すると10MBになりました。-97%です。（ディスク使用量（MB）でなく、割合（％）に着目ください）
高速に回るAI駆動の開発サイクルは、試行錯誤の中間ファイルを同じ速度で積み上げます。そしてクリーンアップの過程で、別のものを発見しました——コードにセキュリティ脆弱性がありました。AIが生成したコードに潜むリスクと、何を確認すべきかを知っている人間がいることの意味を書きます。
プロジェクトフォルダが肥大化していた
このとき初めて、プロジェクトフォルダの全体を見渡しました。
サイズは356MBでした。
最初に確認したときは20MB程度でした。それが17倍以上に膨れていました。コードそのものはそれほど多くありません。では何がそこにあるかというと、ビルドの中間ファイル、テスト用の出力ファイル、参照したPDF、過去のバックアップ、重複したアーカイブです。
そして最大の要因の一つが、画像交じりのPDFから試験問題テキストを抽出するために使ったOCRツールの残骸でした。PyTorch（機械学習フレームワーク）と関連する推論モデルを導入しており、取り込んだ画像を含め、数百MBを占めていました。目的が終わった後も、フォルダに居座り続けていました。
作りながら出続けた作業のゴミが、積み重なっていました。
不要なファイルを整理して、プロジェクトをクリーンにしたいと伝えると、削除すべきファイルとその理由がリストアップされました。ビルド成果物（再生成可能）、テスト出力（本番不要）、変換用の元素材（処理済み）、古いバックアップ（重複）。
整理が終わった後のサイズは10MB。-97%でした。
汚れるのは当然だという認識
このクリーンアップを通じて、一つの認識が整理されました。
機械学習の世界にGarbage In, Garbage Out（入力がゴミなら出力もゴミ）という原則があります。これはデータの話ですが、開発環境にも似た構造があると思っています。
AI駆動の開発では、問いを出して実装を受け取るフィードバックループが高速で回ります。その分だけ、試行錯誤の中間ファイルやリトライの痕跡も速く積み上がります。どこにゴミが貯まるかを把握し、定期的に確認・クリーンアップすることも、設計の一部です。
これはAI開発特有の問題ではありません。人間が開発しても同じことは起きます。ただ、スピードが上がる分だけ、汚れるスピードも上がります。
SIer時代、大規模プロジェクトでの技術的負債の問題を何度も見てきました。動いているからいいじゃないかという判断が重なり、後から整理するコストが積み上がります。今回のクリーンアップは、その教訓を小さなスケールで実践したものです。
定期的に立ち止まり、整理する。 これは開発の速度を落とすのではなく、長期的な速度を維持するための行為です。
そして、セキュリティ脆弱性が見つかった
クリーンアップの過程で、もう一つの作業をしました。コードの全体的な見直しです。
そこで、コードを観点別に整理してセキュリティの監査をするよう指示しました。どのような攻撃ベクタが考えられるか、入力検証・ファイル操作・認証周りを重点的に確認してほしいという形で伝えました。
発見されたのが、バックアップのリストア機能に潜むセキュリティ脆弱性でした。
ZIPパストラバーサル攻撃と呼ばれる種類のリスクです。
バックアップファイルは.lsbackupという独自拡張子のZIPです。このZIPを展開するとき、中に含まれるファイルのパスを検証していませんでした。悪意を持って作られたZIPファイルを展開すると、意図しない場所にファイルが書き込まれる可能性があります。
AIが評価した深刻度は中でした。修正は数行でした。展開先のパスをpathlib.resolve()で正規化し、指定ディレクトリの外に出ないことを確認してから展開します。この修正はEXEの配布前に完了しています。
AIが生成したコードとセキュリティ
生成AIの登場で、コードを書いたことのない人間でも動くものを作れるようになりました。ノーコード・ローコードに加えて、AIが補完するプロコードまで、実装の敷居は急速に下がっています。
ただし、これは危うさを内包しています。機能を動かす知識と、非機能要件（セキュリティ・性能・可用性・保守性など）を設計する知識は別物です。さらに著作権などの法的リスクについては、AIが指摘することもありますが、体系的ではないという認識です。機能の実装を優先するため、聞かなければ見落とされやすい領域です。
この発見は、重要な問いを提起します。
AIが生成したコードは、セキュリティの観点で信頼できるか。
答えはケースによります。
今回の脆弱性は、AIが意図的にリスクのあるコードを書いたわけではありません。単純に、実装の際にパス検証が省略されていました。人間が書いても同じミスをする可能性があります。
ただ、AIは動くコードを生成することに最適化されています。セキュリティの考慮は、意識的に問わなければ優先度が下がりやすいです。また、AIが自信満々に問題のない実装だと示すこともあります。
このコードにセキュリティ上のリスクはあるかと問えば、AIは丁寧にリスクを指摘します。問わなければ、指摘しないこともあります。ただし、問い方にも工夫が必要です。セキュリティ上の問題はありますか？とだけ聞くと、表面的な回答で終わることがあります。攻撃ベクタ・入力検証・認証・ファイル操作など観点を明示して問うことで、構造化された診断が返ってきます。現段階では、何を聞くべきかを知っている人間がいることが、AIをセキュリティのガードレールとして機能させる条件です。
セキュリティを例にすると、OWASP Top 10やOWASP Agentic AI Top 10のようなリスク分類を参照させることで、AIが自発的には考慮しない観点をカバーできます。
さらに一歩進めると、組織ごとの設計基準やルールをAIへのインプットとして体系化した、いわばゴールデンパターンの様な基準を確立できれば、組織での利用時も品質の底上げが可能になると考えています。
診断の手段も、既存のツールと組み合わせて、AIが補完しコードの文脈などを理解した上で、この実装の意図からすると、ここがリスクになりうるなどの推論ができるようになってきたと考えています。今回は手動での確認指示でしたが、観点を明示して問うだけで構造化された診断が返ってくる体験は、従来のツールとは質が違うと感じました。
配布ドキュメントという最後の1マイル
配布用アプリと一緒に渡すREADMEとLICENSEも作りました。配布するということは、自分の管理外に渡るということでもあります。
READMEは対話で完成しましたが、ここで一つ反省があります。機能追加のたびにリリースノートや関連ページ、機能説明を自動で更新するように指示していたところ、修正のたびに新機能として書かれてしまったり、タイムスタンプが前後したりする問題が出ました。指示の出し方の難しさを実感した経験です。
技術ドキュメントを書く力は、エンジニアにもコンサルタントにも必要なスキルです。誰が読むか、何を知っていて、何を知らないかを想像する力。AIはその想像を代替しません。でも、初稿を0から書く作業は代替できます。
ドキュメントのコストが下がると、ドキュメントの質を上げる議論に時間を使えるようになる。
過去に、これを実感した場面があります。非技術者が管理されていた大規模で複雑なレポートファイル作成の仕組みをBI環境に移行したことがあります。移行前は、レポート準備に追われて新しい分析や本来やりたい業務に時間が取れない状況でした。移行後、その方は新しい観点での分析や業務に時間を大きく使えるようになったと喜んでいました。
作業のコストを下げることは、仕事の質を上げることと同義です。
この構造は、今回のツール開発でも同じです。リリースノート、サイト内のヘルプページ、インタラクティブなチュートリアル、機能説明の資料。新機能を追加したとき、それぞれに反映を依頼すれば、すべて対応してくれます。ドキュメントが機能の更新に追いついてきます。
作るより守る方が地味で、重要
この話で書いてきたことは、地味な内容です。
ファイルの削除。脆弱性の修正。ドキュメント整備。これらは、派手さはありません。
でも私はこの一連の作業を、開発の中で最も重要な仕事の一つだと思っています。
コンサルティングでも同じです。華やかな提案より、実装後の安定稼働と運用の設計の方が、クライアントに与える長期的な価値は大きいこともあります。作ることと守ることは、セットでなければなりません。
AIが生成したコードを動かし続けるために、人間が担う保守の目線があります。この目線を持てるかどうかが、AI時代のエンジニアリングの分岐点の一つです。
作ることに目が向きがちな時代に、守ることの価値を理解して動ける人間の需要は、むしろ上がり続けているのではないでしょうか。
次回は、JSONファイルからデータベースへのデータ移行と、マルチユーザー対応の実装について書きます。今使える形を作りながら将来変わる部分を見越した設計判断の話です。
→ 第6回（近日公開）
この記事はシリーズの第5回です。続きを見逃さないようフォローしていただけると嬉しいです。
Accenture Japan - ICE (有志) により固定
インフラストラクチャ・エンジニアリングサービス | アクセンチュア
クラウドアーキテクト / エンジニア / コンサルタント – テクノロジー コンサルティング本部（ICE）
クラウド領域の仕事と募集要項 | アクセンチュア
採用情報 | アクセンチュア
アクセンチュア株式会社に所属する社員有志による運営です。アクセンチュアの社員による様々な発信をまとめています。なお、投稿内容は社員個人の見解であり、所属する組織を代表するものではありません。
Discussion