マイク）
おはようございます、マイクです。「zenncast」のお時間です。
今日は二千二十六年八月八日、土曜日の朝七時を回ったところですね。みなさん、いかがお過ごしでしょうか。
この時間は、技術系ナレッジプラットフォーム「Zenn」から、きょうトレンドになっている記事をピックアップしてご紹介していきます。エンジニアの方はもちろん、「なんとなく最近のAIとか開発の話、押さえておきたいな〜」という方にも分かりやすくお届けしていきますので、どうぞ最後までお付き合いください。
きょうはお便りはお休みということで、そのぶん記事をじっくりめにご紹介していきますね。
さて、きょう紹介する記事は、ぜんぶで五本です。
AI時代の新しいナレッジ管理の話から、AIコードレビュー、ゲーム開発、セキュリティ、そして楽観ロックの基本まで、幅広く攻めていきます。
まず一つ目。
「OKF」という聞きなれないキーワードなんですが、これはGoogle Cloudが提案した、LLM向けの「第二の脳」、いわゆる「LLM Wiki」パターンを標準化しようとしている仕様の話です。
なにをやりたいかというと、LLMが使う「知識」を、マークダウンとYAMLで、小さい単位に分けて、リンクでつなぎながら整理・再利用できるようにしよう、という発想なんですね。
いままでのRAGとかGraphRAGって、「生データを検索して取ってくる」のは得意なんですけど、どうしてもチャンクごとに文脈が切れやすかったり、毎回同じ推論を一からやり直していたり、ちょっともったいないところがあった。
そこで「生データとLLMのあいだにWiki層を置こう」というのが「LLM Wiki」という考え方で、OKFはそのWiki層を標準化しましょう、という話です。
具体的には、「OKFバンドル」と呼ばれる共通のファイル構造を決めて、各ファイルの先頭には`type`を持ったYAMLのフロントマターを書きます。で、本文はマークダウンで書いて、その中のリンクを使って「この知識はあれとつながってるよ」とか、関係を表現していく。
これをやることで、ツールごとにバラバラだったフォーマットが揃って、どの組織でも同じ形で読み書きできるし、「一個のパーサーを書けば、いろんなツール・いろんなプロジェクトの知識を一気に扱えるよね」という世界を狙っているわけです。相互運用性とか、ナレッジの持ち運びやすさがかなり期待できるよ、という話。
もちろんいいことづくめではなくて、標準化されるのはあくまで「構造」だけなんですね。フィールド名とか、その意味まで完全に揃うわけじゃない。
それから、「LLMがいつも正しいマークダウンを吐いてくれるとは限らない」とか、「Wikiにした知識を最新に保つ運用の仕組みは仕様の外ですよ」といった弱点もちゃんと指摘されています。
ただ、RAGとOKFって、どっちを取るか、という対立の話ではなくて、役割分担しましょうね、という結論になっていて。
たとえば、仕様書とか設計のように「安定していて、繰り返し使う事実」はOKFでまとめる。一方で、日々たくさん増えていくログとかチケットのコメントみたいな、「変化が速い生データ」はRAGで検索する。この二段構えで使うのが現実的だよ、と説明されています。
大事な知識をWikiとしてちゃんと育てたい人と、「でもRAGの便利さも捨てたくないんだよな〜」という人、両方に刺さる内容でした。
。。。。
続いて二つ目は、「AIコードレビューを使って、Pull Requestの承認まで自動化しちゃいました」という事例のお話です。
まず筆者がやったのは、「人間のコードレビューって実際どれくらい役に立ってるんだっけ？」という現状分析なんですね。
実際に見てみると、なんと人間レビューの六割が「無言のapprove」か「LGTMだけ」で終わっていて、本当に中身に突っ込んでいる指摘はごく一部だったそうです。
そこで、「どこを人間が必ず見るべきなのか」をはっきり決めて、それ以外はAIに任せよう、という割り切りに踏み切ります。
たとえば、決済処理とか売上計算みたいな「ビジネス的にめちゃくちゃ重要な部分」は、ファイルパスなどから機械的に判定して、問答無用で人間レビューに回す。
それ以外の部分については、LLMに「ここは人間が見るべきかどうか」を八つの観点でチェックさせるんですね。
その八つの観点の例としては、「セキュリティ境界をまたいでないか」とか、「取り返しのつかないデータ削除が入っていないか」とか、「個人情報のフローが変わっていないか」とか。
で、AIは二種類の判断を出します。一つは「このPRの内容そのものに対しての意見」で、approve、pending、need fixのどれか。もう一つは「人間レビューが要るかどうか」で、requiredかoptionalか。ここをちゃんと分けているのがポイントです。
さらに、PRの差分の外側、いわゆる前提条件が関わるようなケースもありますよね。そういうときは、AIが「pending」という判定にして、作者に質問を投げます。
その回答内容を踏まえて再審査して、問題がなければそのままAIがapproveまで進める、という流れになっているそうです。
この仕組みを入れた結果、なんと全PRのうち約五十八パーセントがAIによって承認されるようになったとのこと。
人間のレビューがボトルネックになりにくい状態にかなり近づいていて、レビューの遅延で開発が止まりづらくなった、という評価がされていました。
「ぜんぶAIに丸投げ」ではなくて、「どこだけは人間が絶対見るか」をちゃんと決めて線引きしているのが、多分うまくいっているポイントなんでしょうね。
。。。。
三つ目は、ゲーム開発の体験談です。
unity1weekに出した自作の落ち物パズルゲームが、「なんか面白くないんだよな……」という状態から抜け出せなくて、その原因を、AIに八千回プレイさせて統計を取ることで特定した、という話です。
やったことがおもしろくて、まずゲームの「ルール部分」だけをUnityから切り離して、単体でコンパイルできるようにします。
そのうえで、打ち方の違う何種類かのAIプレイヤーを用意して、ひたすら大量にプレイさせる。
その結果なにが分かったかというと、「連鎖を狙うAI」でさえ二連鎖以上が一度も起きていない。しかも、盤面もほとんど積み上がっていない。
つまり、ゲームとして「盛り上がるはずのポイント」に全然たどり着いていないことが、数字ではっきりしてしまったんですね。
原因はゲームのルール設計にありました。玉を落としたときに、「既にある玉に吸い込まれてしまう」ような挙動をしていて、結果として盤面がぜんぜん増えない。
そのせいで、せっかく連鎖の処理を書いていても、一切発動するタイミングが来ない、という状態になっていたわけです。
ここで、玉の積み方のロジックを一箇所だけ直します。「かたまりが形を保ったまま、ちゃんと積まれる」ように変えたところ、統計がガラッと変わった。
連鎖回数も上がるし、盤面の高さもちゃんと積み上がるようになって、開発者が狙っていた「こういう遊び心地にしたい」という状態にやっと近づいたそうです。
おもしろい指摘だなと思ったのが、「人間でプレイテストしているだけだと、『たまたま出てないだけなのか』それとも『ルール的に絶対出ないのか』の区別がつかない」という話。
でもAIに大量試行させると、「二連鎖がゼロ回です」とか、「平均の盤面の高さはこれくらいです」と、数値ではっきり出る。そこで初めて、「あ、そもそも仕様として無理だったんだ」と気づけるわけです。
筆者は、「つい演出とか見た目の派手さのほうに意識が行きがちだけど、『面白くなさ』の根っこは、だいたいゲームルールとか、もっと下の層にある」ということを強調しています。
そして、ルール部分をゲームエンジンから独立させておくと、こんなふうにAIに大量プレイさせて検証できるし、これはゲーム以外のソフトにも応用できるよ、とまとめていました。
「なんかイマイチだな」とモヤモヤしてるときに、統計で殴る、みたいなアプローチは、けっこう勇気をもらえますね。
。。。。
四つ目は、AIがコードを書く現場でのセキュリティの話です。
AIにコードを書かせるようになると、Pull Requestの数がどんどん増えていきますよね。そうすると、人間のレビューやセキュリティチェックが追いつかなくなって、肝心なところで見落としが出ちゃう、という課題があります。
筆者はそこに、Claude公式の「Security Guidance Plugin」を導入するとどうなるかを試しています。
このプラグインを入れると、「Claudeが生成したコードを、別のClaudeがその場で自動レビューしてくれる」という形になって、PRやCIに到達する前に、危ない書き方をかなり減らせるんじゃないか、という話です。
動き方が三段階に分かれていて、まず一段階目は「編集直後の文字列パターンチェック」。
二段階目は「Claudeが返答する直前に、AI自身によるレビュー」。
そして三段階目が、「commitするときに、もう少し広い範囲をまとめてチェックするレビュー」。
この三つのフェーズで動くんですけど、どれも開発者の手を止めない形で裏側で働いてくれる、というのがポイントです。
実験では、典型的な五種類の脆弱性を全部検知できていて、ただの文字列マッチでは拾えないようなケースも、AIがちゃんとカバーしてくれたそうです。
一方で、テストコードとかコメントに対して「これは危ないかも」と誤検知しちゃうことがあったり、Bash経由でファイルを編集した場合は素通りしてしまうといった限界もあります。
なので、「これだけ入れればPRレビューも静的解析もいりません！」というものではないですよ、ときちんと説明されています。
それでも、導入は設定一行、数分でできてしまうし、誤検知も実測ではそこまで多くなかったので、「とりあえず入れてみて、自分のリポジトリでどの程度効くのかを測る価値は大いにある」と結論づけていました。
AIがAIを監査する、みたいな構図が、だんだん現実のものになってきている感じがしますね。
。。。。
そして五つ目、ラストはデータベースの「楽観ロック」の話です。
楽観ロックってなにかというと、「複数人が同じデータを同時に編集しても、誰かの変更がこっそり上書きされちゃわないようにする仕組み」です。
イメージとしては、「編集画面を開いたときの状態」と「保存ボタンを押したときの状態」を比べて、そのあいだに誰かが更新していたら、自分の更新は弾く。
「あなたが編集しているあいだに別の更新が入りましたよ」と教えてくれて、ユーザーにマージなり再編集なりを促す、という考え方ですね。
実装の基本はすごくシンプルで、テーブルに`version`というカラムを一つ足します。
これは「更新のたびに必ず一ずつ増えていく整数」です。
で、編集画面のときに、このversionの値も一緒にクライアント側に持たせておきます。
保存するときは、「`WHERE id = ? AND version = ?`」という条件付きで一発のUPDATE文を投げる。
もし他の誰かが先に更新していてversionが変わっていたら、このUPDATEの影響行数がゼロになるので、「あ、これは競合したな」と判定できるわけです。
ポイントは、「比較」と「書き込み」を一本のUPDATE文で同時にやる、つまりアトミックにすること。
注意点として挙げられているのが、よくありがちな`updated_at`みたいな時刻カラムを競合判定に使うパターンです。
これをやると、「一秒以内に複数回更新された場合に検出できない」とか、精度の問題が出てきてしまうので不適切だよ、と。
また、アプリ側で「まずSELECTで比較してから、そのあとでUPDATEで書き込む」というふうに、二本のSQLを分けて書いてしまうと、そのあいだに他の更新が割り込めてしまうので、結局「更新データの喪失を防げない」ということも、具体例付きで説明されています。
なので、「versionカラムを持たせて、一本のUPDATEで比較と更新を同時にやる」というのが、シンプルだけど一番堅いパターンですよ、という整理になっていました。
。。。。
ということで、きょうご紹介した記事を、駆け足でおさらいしておきます。
まず一つ目は、Google Cloud発の「OKF」という仕様を通じて、LLMのための「第二の脳＝LLM Wiki」をマークダウンとYAMLで標準化していこう、という話。
二つ目は、「どこを人間が見るべきか」をはっきり決めて、それ以外はAIコードレビューに任せることで、PRの約五十八パーセントをAIが承認するようになった事例。
三つ目は、自作パズルゲームをAIに八千回プレイさせて、「面白くない原因」がルール設計にあると統計的に突き止めた体験談。
四つ目は、ClaudeのSecurity Guidance Pluginで、AIが書いたコードを別のAIがその場で三段階チェックして、PRやCIに行く前に危険な書き方を減らしていこうという取り組み。
そして五つ目は、versionカラムを使った楽観ロックの基本的な実装と、やってはいけない落とし穴の話でした。
きょう気になった記事があれば、このあとショーノートにタイトルをまとめておきますので、ぜひ元の記事も読んでみてください。細かい図やサンプル、具体的なSQLなんかは、やっぱり本編を見てもらうのが一番分かりやすいと思います。
「zenncast」では、番組の感想や、「こんなテーマを掘り下げてほしい」といったリクエストもお待ちしています。
普段どんな技術に触れているのか、とか、「AIとの付き合い方こうしてます」みたいな話も、ぜひ教えてください。
それでは、そろそろお別れの時間です。
お相手はマイクでした。また次回の「zenncast」でお会いしましょう。いってらっしゃい！