つぶやく
冒頭，氏は「AIがコードを速く作るほど，私たちはそのコードをよく理解できているのか」と問いかけ，「正直，よく理解できているとは言いがたい」と切り出した。その取り組みは，コードレビュー時間を95%削減（年間670時間が33時間に）するという具体的な成果をすでに生んでいる。
 |
AI時代の最も目立つ変化の一つがコードレビューのボトルネックだ。かつて数日かかったコードが今は数分で生まれる。生成コストは劇的に下がったのに，理解（レビュー）にかかる時間とコストはそのまま――この非対称が広がり，レビューに現れている。氏が示した「Cortex 2026エンジニアリングベンチマーク」では，PR（プルリクエスト）の量が20％増えた一方，レビュー時間は91％増（ほぼ2倍）。しかも，2倍の時間をかけてもPRあたりの問題件数はむしろ23.5％増えていた。「時間を増やして結果が悪くなるのは，今のやり方自体に問題があるという信号です」。
原因は，コード生成の速度に理解の速度が追いつかないこと。氏はこれを「理解負債（Comprehension Debt）」と名づける。技術負債は目に見えて測定でき，いつか返すと皆が知っている。
だが理解負債は氷山のように水面下が本体で，「コードはあるのに，理解した人はいない」まま使われ続ける。ゲーム開発はAI以前から，原作者がチームを去り文書もほとんどない数百万行のレガシーコードという問題を抱えていた。そこにAI生成コードが加わり，レガシー負債とAI負債が同時に積み上がって理解負債が加速している，というわけだ。
 |
この問いから生まれたのが，「CodeOnBoard」＝理解負債を返済するAIだ。コードベースを理解し，さらにコード生成まで助けるAIパートナーで，開発ワークフロー全体に積もった理解負債を返しながらAX（AI Transformation，AIによる開発変革）転換を導くことを目指す。商用ツールが多い中で自作を選んだのは，ゲーム開発固有の壁があったからだ。
コード資産はセキュリティ上ほぼ社外に出せず，社内インフラで動く自前ソリューションが必要になる。VCS（バージョン管理システム）の問題もある――多くのツールはWeb／GitHub・GitLab中心だが，ゲーム開発はPerforceやSVNを多用し，独自スクリプトはパースすらされない。さらに独自スクリプト言語やドメイン特殊性が多く，汎用ツールではゲームドメインに必要な精度が出ない，という判断もあった。
氏は具体例を挙げた。ItemServiceクラスのAddItem関数で，「count 0を不許可」だった条件が「0を許容」に緩和された。差分（diff）だけ見れば単なる条件緩和だ。だが差分にない本当の文脈は呼び出し元にある――countが0で呼ばれるとtrueを返し，報酬ゼロなのに報酬獲得ポップアップが出るバグがある。この文脈がAIに伝わらないと見逃される。
そこでCodeOnBoardは，変更された関数の全体と，その呼び出し元・呼び出し先をコードベースから直接検索し，周辺文脈を先に把握してからレビューする。人がコードを辿りながらレビューする行動をAIに行わせたのだ。同じ差分でも"見る範囲"が変わるため，捕まる問題がまったく変わる。
 |
その検索はさらに一歩進み，「自己改善ループ」として設計された。コード検索は正確に探すと遅く，速く探すと精度が落ちる。そこで一度成功した検索パターンを保存先に記憶し，次のレビューでFew-shotとして再利用する。ここに至るまでには，マッチ率と遅延のせめぎ合いという試行錯誤があった。当初の固定Few-shotによる検索用正規表現生成では，マッチ率43％・完全失敗35％とコードベースごとのスタイル差で脆弱だった。
次に，検索失敗時にLLMへ最大3回まで再要求するループを足すとマッチ率は大きく回復したが，再生成コストで遅延が増えた。最終形の自己改善ループ（成功パターンをキャッシュし動的Few-shotを再注入）では，平均マッチ率92％・完全成功77％に達し，再生成コストと遅延も減少。「使うほど改善される構造」になった。
 |
エンジンが良くても，ゲーム開発の現場に溶け込まなければ意味がない。そこで当初からもう一つの大きな軸として開発環境との統合を据えた。GitLab・SVN・Perforceをすべてサポートし，GitLabのマージリクエストやPerforceのシェルブといった既存の社内ワークフローと統合。レビュー成果物は，変更意図を素早く把握できる「理解を助けるレポート」（差分分析＋変更意図＋品質評価），規約・セキュリティ・品質を行単位で指摘する「コメント単位レビュー」，そして実装が企画から外れる瞬間を捕らえる「企画書レビュー」（企画書を変換しスペック準拠を検証。まだ初期段階で高度化中）の3種だ。
実際にネクソンのあるゲーム開発チームへ導入したところ，効果は明確だった。従来は1対1の対面レビューで，レビューを受ける側はシニア開発者の空き時間を待ち，シニア側もコンテキストスイッチで本来作業が滞るという双方向のボトルネックがあった。導入後は開発直後にまずAIがリアルタイムでレビューし，最終段階でチームレビューが入る構造に変わり，レビュー時間は95％削減。1件1〜2時間が5〜20分になり，年換算で670時間が33時間に。「より意味があるのは，レビューという"非開発時間"を純粋な開発時間へ転換できた点です」と氏は語る。
品質面でも，オープンソースベースのコードレビュー・ベンチマークでPython 67.7％／Java 62.5％のリコール（実際のバグ・問題をどれだけ見つけたか）を記録し，Claude Code Reviewer・GitHub Copilot・CodeRabbitといった主要グローバルツールの1.5倍以上だったという。
 |
AIコードレビューは「変更コード単位の理解負債」を解決し，レビュー時間とボトルネックを除去し，変更品質も確保した。だが残るのがコードベース全体単位の理解負債だ。文書はない／あっても古い，開発者は読む時間がない，文書は各所に断片化している。ここで出した結論が「人ができないなら，システムが"理解"を資産化すべきだ」。毎回ゼロから理解し直すのではなく，理解そのものをシステムが蓄積し，資産のように積み上げる構造を作る――これがコードベース資産化だ。
氏は，今のコードベースを「倉庫」に例える。コードは積まれているが，どこに何があるか分からず，理解なしには探せず使えない。一方「図書館」は分類・索引があり，本同士が連結した知識体系を持ち，検索で文脈ごと理解できる。倉庫を図書館に変えることが資産化だ。汎用AIにコード全体を渡す方式には構造的限界がある――セッションごとの全インデックス化（巨大なほど遅く高コスト，精度低下），暗黙的な連結の検出困難（grepで辿れない／不要な文脈混入），ゲームドメイン学習の希少さ，そして蓄積した文脈がリセットで消える点だ。
資産化すれば，一度構築すれば再利用でき，暗黙的連結も静的解析とパターンで追跡でき，独自スクリプトもデータ化でき，使うほど成長し，組織全体が同じ知識を共有する。最終目標は，蓄積データを統合・高度化し，AIに常に最適な文脈を与える"コンテキストレイヤー"を作ること。あらゆる作業がその上で動く。
 |
資産化のデータ構造も図書館の比喩で示された。RDBは本の題名・著者・分野＝関数やクラスの名前・パス・言語など静的解析で得た構造化情報（カタログ）。ベクトルDBは似た主題の本をまとめる本棚＝関数・クラスの要約を埋め込み，意味の近いコードを探す。ナレッジグラフは参考文献・引用関係＝関数・クラス間の関係をグラフ化し，影響範囲を追跡する。この3つを統合し，同じコードを3つの視点で見られるようにした。
資産化は2段階のパイプラインで進む。第1段はコード静的解析（新しい本を1冊ずつ読みカタログに登録）。文書生成では当初，完全自動を試したが，ロギングやイベント処理，データシリアライズのユーティリティなど"頻繁に参照されるがドメインの核心ではないもの"が目次の中心に来てしまった。そこでヒューマン・イン・ザ・ループへ転換。目次の初稿はAIが全生成し，人が編集・並べ替え・追加削除して最終確認すると，AIが文書を生成する。人の判断とAIの生産性の両取りだ。
この文書エージェントは職種ごとの壁を崩した。新規合流者はどこから見るべきか分からないが，自動生成文書で核心を素早く把握できる。開発者は文書の自動生成・更新で執筆時間が減る。PM・企画者はコードは読めないが構造は知りたい場面が多く，ドメイン視点のシステム概要文書でコードなしに一部構造を把握できる。成果物として，人が磨いた目次に沿って技術文書が自動生成され，コードの関係や実行フローのダイアグラムまで自動で作られる。
 |
第2の活用がCodeOnBoardエージェントとCLIだ。資産化した知識を，ターミナルからエージェント／CLIで直接使える。核心は「文書を探しに行くのではなく，問い合わせでコードベースを理解する」。ターミナルで「ダメージ計算ロジックはどこ？」と問えば，資産化したナレッジグラフ上で生成された答えが返る。チャットアシスタントとCLIターミナルアシスタントを提供し，既存のCopilotやCursor，Claude Codeとも統合可能。チャット内でレビューの追加質問や「今の関数のより詳しい文書を作って」といったカスタム文書生成もできる。
もっとも課題は残る。AIが存在しない内容を作る／誤った動作を説明するハルシネーション，そして検索が失敗すると答えの品質が落ちる検索品質・精度とカバレッジの問題だ。Harness Engineering・LLM-as-Judge・Rerankingといった手法を研究・テストし適用しており，「完璧な道具ではないが，一歩ずつ良くなっている」とした。
 |
最終章は開発ワークフロー完全自律化へのロードマップ。AIが実行し，人は検収と意思決定のみを担う構造だ。「開発者の役割は，コードを書く人から，方向を決める人へ変わる」。エンドツーエンド自律化の第1領域は自律テスト生成。AIエージェントが自らユニットテストを生成し，隔離環境で実行・検証し，結果をレポートする。現在PythonでのPoC（概念実証）段階で，テスト結果レポート，コードカバレッジ，イシューと推奨事項を自動生成し，AIが書いたテストコード自体も提示して有意なテストか検討できる。今後はゲームスクリプト言語や他言語への拡張が目標だ。
第2領域はコード生成の自動化。ただし一般的なコード生成やリファクタリングとは少し異なり，目標はAIが理解・修正・拡張しやすい"AIフレンドリー"なコードベースへ再構成し，最終結果を人が検討すること。多くの限界が生じるとしつつ，「この構造が噛み合った瞬間，実行はAIが主導し意思決定は人が担うエンドツーエンド自律化が完成する」と語る。
ジン氏は最後にこう述べた。「AI時代に生成は本当に簡単になり，誰でも成果物を作れる。しかし理解のない成果物は，資産ではなくただのより多くの負債にすぎない。AIが速く発展し，人の介入のない完全自律化が近づくほど，人の理解はより深いところで，より重要になる。消えるのではなく，場所が変わるのです。CodeOnBoardは，その変わった場所で，人の理解が最後までコードに届くための道具になることを目指しています」。
この日のセッションで示されたのは，AIをコード生成の加速装置として使うだけでは足りないという認識だった。速く作れるようになった分だけ，理解が追いつかない領域が広がる――その構造的な矛盾に正面から向き合い，レビューから資産化，自律化まで一貫したシステムとして応答しようとする姿勢は，ゲーム開発という保守的な現場ほど刺さる話だと感じた。
印象的だったのは，「完全自律化が近づくほど，人の理解はより重要になる」という逆説的な結論を，氏が称揚ではなく冷静に語った点だ。自律化を謳いながら，ヒューマン・イン・ザ・ループを手放さなかった理由がここにある。自動化の進展に合わせて人の関与を減らすのではなく，人の関与の質を上げることに投資していた。
数値（レビュー時間95%削減，年670時間→33時間）はジン氏の発言に基づくものであり，対象チームや計測条件の詳細は確認できていない。ただ，AIコードレビューが現場のフローを実際に変えられることは，この日の話から十分に伝わった。
