どうも、マイクです。おはようございます。
七月二十三日、木曜日の朝七時を回りました。ここからの時間は「zenncast」、今日も最新のテックトレンドを、Zennの記事からわかりやすくお届けしていきます。

さて今日は、Zennで話題になっているトレンド記事を、ぜんぶで五本ご紹介していきます。どれも「既存の開発スタイルをどうアップデートしていくか」という共通テーマがあって、聞き応えたっぷりのラインナップになっています。

まず一本目。
Cやシープラスプラスで書かれた既存コードを、ほとんど書き直さずに、なんと「コンパイルし直すだけでメモリ安全にしてしまおう」という、かなり攻めたツールチェーン、Fil‐Cを紹介している記事です。

このFil‐Cは、クランベースのコンパイラと専用ランタイムのセットになっていて、言語としてはふつうのC／シープラスプラスの文法や拡張がそのまま使えます。一方で、ラストのアンセーフみたいな「ここは自己責任で危険なことをします」という抜け道は用意されていなくて、安全でないバイナリともリンクできない、というかなり徹底したポリシーを取っています。

Fil‐Cの肝になっている仕組みが「インビジキャプス」と呼ばれるもので、すべてのポインタに対して「どの範囲が有効か」「今そのポインタは生きている状態か」といったメタ情報を、こっそり持たせておきます。そのうえで、境界外アクセスとか、解放済みメモリの再利用、いわゆるユースアフターフリーが起きそうになったら、実行時に必ず検出してプロセスを止める、という動作になっているんですね。

さらに独自のガーベジコレクタも組み込まれていて、フリーしたあとのメモリ領域を、すぐには他の用途に再利用しないよう制御することで、攻撃者に悪用されにくくしている、という工夫もあります。

記事では、オープンエスエスエルやシーパイソンといった大規模なソフトウェアでも、実際にFil‐C上で動かしてみた結果が紹介されています。ベンチマークでは、ワークロードによっては、おおよそ一・一倍から二・三倍くらいの遅さに収まっている、ということで、「完全にタダではないけど、実運用を検討できるコスト感だよね」という評価になっています。

既存のC／シープラスプラス資産を捨てずに、メモリ安全性をぐっと高められるので、特にネットワーク境界にいるツールとか、パーサのような「一発バグると致命傷」なところでの利用が有望だ、と筆者は述べています。メモリ安全言語に全部書き換えるのは現実的じゃない、という現場にとって、かなり現実解に近いアプローチだなと感じましたね。

。。。。

続いて二本目。
こちらはAIとの協働で成果物をチェックするときの、「頼み方」にフォーカスした記事です。ポイントは、ただ「レビューしてください」とお願いするよりも、「敵対的検証をしてください」と指示するほうが有効だ、という主張になっています。

ここでいう敵対的検証というのは、「どこかに必ず問題があるはずだ」という前提を置いて、あえて反証を試みてもらうスタイルのチェックです。AIには「この成果物は本当に正しいのか？」「この仕様で本当に安全なのか？」と、あら探しをしてもらうイメージですね。

このとき重要なのが、「判定」と「その根拠」をセットで返してもらうことだと記事では説明しています。たとえば、「この設計は一見よさそうだけど、ここの制約条件と矛盾している可能性があります。理由は〜」という形で出してもらうことで、人間側が「この指摘は採用するか、却下するか」をジャッジしやすくなる、と。

クロードコードでは、この敵対的検証が公式のパターンとして組み込まれていて、サブエージェントが別文脈から、多視点で成果物を検証する仕組みになっています。ただ、チャットジーピーティーなど他のツールでも、まっさらな新規セッションを一個開いて、成果物だけを貼り付けて、「あなたは反証役です」とルールと出力フォーマットを細かく指定してあげれば、同じ型を再現できる、と具体的な使い方も紹介されています。

一方で、この敵対的検証にも注意点があります。ときどき、かなり健全な成果物に対して、無理やり粗探しをして過剰な指摘をしてしまうことがある一方で、逆に甘い「合格」判定をして見逃すケースもある。そして、検証のためにトークンを多く消費するので、コストも高めになりがちです。

そのため、事実確認が必要なところでは、元データや公式ドキュメントといった一次情報をちゃんと参照させること。そして最終的な採否判断は、あくまで人間が行う必要がある、と記事は強調しています。AIを「賢い評論家」ではなく、「ちょっと意地悪な品質保証チーム」として使うイメージですね。

。。。。

三本目は、ビジュアルスタジオコード向けのMarkdownウィジウィグ拡張を題材にした、「ループエンジニアリング」という考え方についてのオピニオン記事です。テーマは、AIを定期的に自動実行させて、開発サイクルをぐるぐる回し続ける、というものですね。

筆者は、「信頼して使えるMarkdownエディタがない」という不満から、自作を決めたそうです。そのうえで、機能をかなり小さく分割して、クロードコードに「スラッシュループ・ツーアワーズ・スラッシュエボルブ」といった形で、二時間おきに一サイクル回すよう設定しました。一サイクルは、「一つの小さな機能を実装して、テストして、自動レビューして、ドキュメントを書いて、コミットする」ところまで、全部AIに任せる仕掛けになっています。

ここで面白いのが、「ロードマップ・ドット・エムディー」をAIの外部記憶として使っている点です。AIはまずこのファイルを見て、バックログに並んだToDoの中から一つ選び、そのタスクを進めます。その際、ちゃんとテストや撤退条件、メインブランチに直接コミット禁止、みたいな細かいガードレールを設定して、AIが暴走しにくい環境を整えているんですね。

人間側の役割はというと、バックログを起票したり、実際のエディタを触って「手触り」を確認したりすることに集中します。具体的には、見出しレベルの視認性が悪いとか、ダークテーマで太字が見えづらいとか、マーメイド図を高解像度でコピーしたいのにうまくいかない、とか。そういった「使ってみないとわからない小さな不満」を見つけて言語化するのが、人間の役割だと位置づけています。そして、その修正の実装は基本AIに任せる、という分業ですね。

記事では、大きなアーキテクチャ設計や、UIの「気持ちよさ」といった、自動テストしづらい部分は人間が担当するべきだとしています。一方で、「細かく分割できて、テストできちんと守れる部分」はAIのループに向いている。どこまでをAIループに任せ、どこからを人間の判断領域にするのか、その境目と配線を設計することこそが、ループエンジニアリングなんだ、という結論で記事は締めくくられています。

。。。。

四本目は、ゲーム開発者必見の話題。Unity公式のコマンドラインツール、Unity CLIと、その拡張パッケージである「コム・ユニティ・パイプライン」を使うことで、UnityエディタをHTTP経由で、ほぼ完全に遠隔操作できる、という内容の記事です。

このUnity CLIからは、エディタの起動やビルド、テストはもちろん、シーンやゲームオブジェクトの生成、シーシャープコードの実行、スクリーンショットの取得まで、ざっと百四十種類くらいのコマンドが用意されています。エディタが起動している状態でも、外からどんどん操作できるようになっているんですね。

筆者はこのAPIセットをクロードコード、つまりAIエージェントに渡して、「ブロック崩しのゲームを作って」と指示してみたそうです。すると、なんと人間がエディタを一切触らないまま、シーンの作成からスクリプトの実装、再コンパイル、プレイモードでの動作検証、デバッグ、見た目の確認、スクリーンショット取得まで、自動で最後まで完走した、という報告がされています。

ここで効いているのが、「イーヴァル」コマンドによるゲーム内オブジェクトの操作と状態検証、それから「スクリーンショット」コマンドによる見た目チェックです。AIが「自分で作って、自分でテストして、自分で見た目を確認して改善する」というループを回せるようになっている、というのが大きなポイントですね。

もちろんいい話だけではなくて、記事では不安定さや制約も率直に指摘されています。たとえば、エディタ検出に使うポート記述ファイルがなぜか消えてしまう、といった「ああ、まだベータ版っぽいな」というトラブルもあったそうです。

それでも総じて、Unity CLIとパイプラインパッケージの組み合わせは、これまでバッチモードや自作のスクリプトに頼っていたUnityの自動化を、大きく変えうる存在だと評価しています。継続的インテグレーションだけじゃなくて、AIエージェントと組み合わせた「新しいUnity開発の土台」になり得る、と。ゲーム開発現場のワークフローも、数年単位でガラッと変わりそうな予感がしますね。

。。。。

そして五本目。
こちらは、事業的な締め切り付きの開発を、AIと一緒にどう乗り切ったか、というリアルな現場の事例です。テーマはLINEチャットボット機能。事業上の理由で、「一ヶ月で出さなきゃいけない」という、なかなかハードな条件です。

ところが、既存コードはかなり複雑で、クロードに読ませようとしても、すぐコンテキストの上限にぶつかってパンクしてしまう状態だった、と。ここで筆者が取った戦略が、「より強いモデルに課金してゴリ押しする」のではなく、ドメインを細かく分け直して、ドキュメントも分割して、ひとつのタスクでAIが読まなきゃいけない範囲を、とにかく小さくしていく、という再設計とリファクタリングでした。

具体的には、診断ロジックやLINE連携など、機能ごとにコンテキストをしっかり分割し直したうえで、データモデリングも見直しています。もともと「一テーブル一モデル」だった設計から、「一集約一モデル」にチェンジして、CQRSを取り入れたり、テーブルをイミュータブルにする設計にしたり。さらに、リポジトリパターンに生のSQLを組み合わせて高速化し、なんと一日かかっていたバッチ処理を、ゼロ・五秒まで短縮した、というインパクトのある数字も出ています。

開発プロセス面では、ユースケース整理やタスク分割をとにかく丁寧に行い、小さなタスク単位でソネットに実装を任せる運用に切り替えました。そのうえで、別セッションのAIやCodeRabbitによる二段階レビューも組み合わせて、「一発書いて終わり」ではない品質確保の体制を作っています。

その結果として、五月だけでコード修正量は十八万行に達し、問題のLINEチャットボット機能も、きちんと期限内にリリースできたそうです。しかも、より弱いモデルを使っていても、コンテキスト上限で悩むことはほとんどなくなった、というのがポイントですね。

筆者はこの経験から、AIコーディングの生産性を決めるのは、モデル性能よりもむしろ「コードとドキュメントのわかりやすさ」だとまとめています。AIを走らせる前に、設計とドキュメントをきちんと整えることこそが、最大のレバレッジなんだ、と。つい「もっと強いモデルを！」と考えがちですけど、その前にやるべき土台作りがある、というのは、多くのチームに刺さるメッセージじゃないかなと思いました。

。。。。

ということで、今日は五本の記事をご紹介してきました。
おさらいすると、まずはC／シープラスプラスの既存コードをコンパイルし直すだけでメモリ安全に近づけるFil‐Cの話。それから、AIに「レビューして」ではなく「敵対的検証して」と頼むことで、より良いチェックができるという話。三本目は、Markdownエディタの開発事例を通じた、AIを定期的に回し続けるループエンジニアリングの考え方。四本目は、Unity CLIとパイプラインを使って、UnityエディタをHTTP経由でほぼフルリモート操作し、AIが自分でゲームを作ってテストする未来の開発フロー。そして最後は、LINEチャットボット開発を、設計とドキュメントの見直しでAIフレンドリーにし、一ヶ月で出し切った現場のストーリーをご紹介しました。

気になる記事があった方は、詳しい内容や元の記事へのリンクはショーノートにまとめてありますので、ぜひそちらからじっくり読んでみてください。

「zenncast」では、番組の感想や、取り上げてほしいテーマ、「こういう現場の話もっと聞きたい！」といったリクエストも大歓迎です。あなたの開発現場での工夫や失敗談なんかも、ぜひ教えてください。

それでは、そろそろお時間です。
今日も一日、楽しく、そして安全にコードを書いていきましょう。
お相手はマイクでした。また次回の「zenncast」でお会いしましょう。ではでは。