どうも、マイクです。おはようございます。
七月五日、日曜日の朝七時をまわりました。「zenncast」、今日も元気にお届けしていきます。
この番組では、Zennに上がっている技術記事の中から、いまホットなトレンド記事をピックアップして、朝イチでゆるっと、でも中身はしっかりめにご紹介していきます。
今日はお便りはお休みということで、そのぶん記事紹介をたっぷりめにいきましょう。
きょうは全部で五本、ご紹介していきます。
まず一つ目。
これは「AIに大部分を書かせたコードを、半年間ガチで運用してみた」というところから、保守しやすさに効いた工夫と、逆にダメだった工夫を振り返っている記事です。
面白いのが、「よかれと思ってやったことが、時間がたつとほぼ全部腐った」という反省なんですね。
たとえば、たくさん足したコメントやドキュメンテーション文字列、早すぎる共通化や抽象化、「わかりやすく書いて」といった曖昧な依頼。こういうのって、一見まじめに保守性を高めてるように見えるんですが、半年運用してみると、コード本体だけが変わってコメントが更新されないとか、抽象化だけが立派で中身は全然違う…みたいな「ズレ」がどんどん溜まっていって、結局保守性を下げてしまったと。
じゃあ何がよかったのかというと、コメントは「なぜそう書いたか」だけを残すこと。
「このライブラリはバグがあるからあえて古いバージョンを使っている」とか、「ビジネス的な理由でここは遅くてもよい」とか、そういう“理由”だけを書く。コードのやり方・手順を書かないので、コードが変わってもコメントが腐りにくいんですね。
それから、AIが書いたコードって、一つの関数に処理をモリモリ詰め込みがちなので、それを人間の側で小さい責務ごとの関数に分割し直すこと。
「入力チェック専用」「外部APIコール専用」「エラー処理専用」みたいに、粒度を揃えた小さな関数にばらしていくと、半年後に読んでも追いやすかったそうです。
さらに重要だったのが、「仕様とテストだけは人間が握り続ける」というルール。
どんなにAIに実装を任せても、最終的な仕様とテストケースは人が決めて、人がレビューする。そうやって「ここだけは変えちゃいけない基準」を人間側で強く持つことで、あとからAIにリファクタリングさせても、システムの本質がぶれにくかったと書かれています。
筆者は、AIは本質的に「足す」方向に働くので、人間は意識して「引き算」をするべきだ、とまとめています。
あれこれコメントを足すんじゃなくて、「理由のコメント」だけに絞る。
複雑な抽象化を足すんじゃなくて、「小さな責務」に分解する。
なんでもAIに投げるんじゃなくて、「変えてはいけない基準」だけは人が握る。
この“引き算”の発想が、AI時代の保守性を守る鍵だという話でした。実際にAIコードを半年運用した生々しい知見なので、チーム開発やっている人にはかなり刺さる内容だと思います。
。。。。
二つ目。
ここからは、Claude Fable Five の話題ですね。この記事は、Claude Fable Five の使い方紹介と、「Agent SOP」という仕組みの導入手順・活用法をまとめた、かなり実践的な Tips 記事になっています。
まずおもしろい前提として、Claude Fable Five は二千二十六年七月までの期間限定、それも利用量に制限がある高性能エージェントなんですね。
そこで筆者が提案しているのが、「期間限定で超優秀なエージェントが雇えてるうちに、その人に全力で“手順書づくり”をお願いしておこう」という発想です。
つまり、Fable Five が使えるあいだに、チーム用の標準手順書をガンガン整備してしまえば、たとえ Fable Five が使えなくなっても、その SOP が半永久的に資産として残るよね、と。
そのための仕組みとして紹介されているのが「Agent SOP」です。
これは標準化された Markdown 形式の手順書、拡張子としてはドットエスオーピーエムディー、というファイルから、Claude Code のスキルとか、MCP 用のプロンプトなんかを自動生成してくれる仕組みになっています。
さらに、「禁止事項には必ず理由を書く」といった品質ルールも持っていて、単なる箇条書きじゃなく、ちゃんと“なぜそうするのか”がわかる SOP を作れるようになっているのがポイントです。
導入手順としては、まずプラグインマーケットプレイスから Agent SOP をインストール。
それから、リポジトリの中に「agent-hyphen-sops」というディレクトリを作って、その中に SOP ファイルを置きます。
Claude Code からは、MCP サーバとして呼び出す方式と、スキルに変換して呼び出す方式、だいたいこの二パターンで連携するイメージですね。
で、本題の Fable Five の使いどころです。
記事では、Fable Five に対して「Agent SOP の仕様調査」をさせて、「作業ログや Git のログから手順候補を抽出させて」、「SOP を実際に書かせて配布方法も考えさせて」、「最後に公式バリデータでチェックさせる」と、ここまで一連の流れを丸っと任せよう、と提案しています。
特に面白いのが、「過去ログから実際に踏んだ罠を拾って、それを Constraints の理由として書かせる」という使い方。
「このコマンドは、以前本番環境を落としたことがあるので、必ずステージングで試してから使うこと」みたいな、そのプロジェクトならではのやらかし履歴を SOP に埋め込むことで、「一般論じゃない、そのチーム専用の高品質な手順書」になっていくんですね。
つまり、期間限定の Fable Five を、あえて“日常業務”ではなく「標準手順の整備」に全振りして、期限が切れたあともチームのナレッジが残るようにする、という戦略の紹介でした。
。。。。
三つ目の記事も、Claude Fable Five 関連です。
こちらは、Fable Five を含む複数モデルの運用 Tips をまとめた内容になっています。
ポイントは、「Fable Five はむちゃくちゃ賢いけど、そのぶんトークン消費が激しい」という現実的な話から始まります。
なので、実装やテストといった手を動かす系の作業は、Opus や Sonnet に任せて、Fable Five には「タスク分解」「方針決定」「結果の統合」だけを担当させると、コスパがいいですよと。
こうすることで、長時間のセッションでも判断のブレが減って、プロジェクト全体としての一貫性が保ちやすくなると説明されています。
で、ここで重要になるのが、「どの仕事をどのエージェントに渡すか」という“サブエージェントのチーム設計”です。
よくあるパターンとして、「考える人」と「作業する人」の二種類だけに分けがちなんですが、それだと粒度が粗すぎる。
記事では、スコープ整理、設計、実装、QA、出荷、といった感じで、工程ごとに役割を細かく分けると、エージェントへの委譲精度が上がると述べています。
たとえば「スコープ整理専用エージェント」「API 設計専任」「ユニットテスト担当」みたいに分けると、それぞれに適したモデルやプロンプト設定ができるわけですね。
ただ、これを毎回手書きで設定するのは大変だよね、ということで、著者が作ったのが Claude Code 用の CLI ツール「ccteams」です。
この ccteams を使うと、「シーシーチームズ スペース ユーズ スペース ジェネラリスト」といったワンコマンドで、役割分担済みのエージェント一式と、そのオーケストレーションルールを自動生成してくれます。
つまり、「どの役割のエージェントを何体用意して、誰が誰に何を頼むか」というルールセットを、ひとまとめでテンプレ化してくれるわけですね。
さらに ccteams には、Nextジェイエス用、Go の API 用、FastAPI 用といった、技術スタック別のチーム定義も同梱されています。
それぞれの役割に対して、既定のモデル割り当ても入っていて、たとえば「Fable Five はオーケストレーター専任」「設計やレビューは Opus」「実装は Sonnet」みたいな感じで最初から設定されている。
加えて、「Codex を別視点のシニアエンジニアとして並走させる」という運用パターンも紹介されていて、複数モデルを“人間の開発チーム”っぽく動かす工夫がいろいろ入っている記事でした。
複数モデル前提の開発をやっている人にとっては、「どのモデルをどこに当てるか」という悩みどころに、かなり具体的なヒントをくれる内容になっています。
。。。。
四つ目。
ここからはガラッと変わって、グラフニューラルネットワーク、G N N の Tips 記事です。
ノードとエッジで構成されるグラフデータに対して、どういうタスクができて、どんな課題があるのかが、きれいに整理されています。
まず G N N が扱える予測タスクとして、三つのレベルが紹介されています。
一つは「ノード単位」での予測。たとえば、ソーシャルグラフ上でユーザーの属性を推定するようなケースですね。
二つ目が「エッジ単位」の予測。これは、ふたりのユーザーの間にフレンド関係がつながりそうかどうか、みたいなリンク予測です。
三つ目が、「グラフ全体」の分類。ケミカルな分子構造を一個のグラフとして見て、それがどんな性質を持つか判定するようなタスクです。
そして代表的なモデルとして、GCN、GAT、GraphSAGE の三つが取り上げられています。
GCN は、隣接ノードの情報を「平均集約」するタイプ。
GAT は、「重要なノードには重みを多めにつけて集約する」アテンション付きのモデル。
GraphSAGE は、「近傍ノードをサンプリングして情報を集める」仕組みで、大規模グラフにスケールしやすいのが特徴だと説明されています。
この記事のメインテーマは、G N N を深くすると起こる「オーバースムージング」、日本語だと過平滑化と訳される問題です。
これは、グラフの近傍情報を混ぜていく処理を何層も繰り返すうちに、どのノードの表現も似通ってしまって、最終的に区別がつかなくなる現象のこと。
特に多層の GCN では、ある層数を超えると一気に精度がガタッと落ちる、というのがよく知られた課題だと紹介されています。
で、このオーバースムージングをどう診断するかという話で、三つの指標が挙げられています。
一つ目が MAD。全ノード間の距離の平均を見る指標で、これが小さくなってくると、「どのノードも似たような場所に押しつぶされてきてるよ」というサインになります。
二つ目が MADGap。これは、「つながっているノード同士の距離」と、「つながっていないノード同士の距離」の差を測るもの。
この差がゼロに近づいていくと、「隣接しているかどうかで表現を区別できなくなってきてる」つまりオーバースムージングが進行中、ということになります。
三つ目が Effective Rank。これは特徴量行列が“実質何次元使えているか”を測る指標で、これが下がってくると「表現の多様性が失われてきている」、危険信号だよ、という説明でした。
対策としては、大きく二種類があります。
ひとつは、グラフ構造そのものを調整する方法。
具体的には、学習時にエッジをランダムに削る DropEdge とか、予測結果を見ながら「違うクラス同士のエッジを切って、同じクラス同士は結び直す」AdaEdge みたいな手法が紹介されています。
これによって、情報が変な方向に伝播しすぎるのを抑えて、過平滑化を防ぐわけですね。
もうひとつが、アーキテクチャ側の工夫です。
残差結合や Dense Connection、JKNet、GCNII といったモデルが例に出されていて、どれも「元の特徴量を、深い層までうまく持ち運ぶ」ような設計になっています。
これによって、「どの層を通っても表現が均質になりすぎないようにする」という発想ですね。
実験としては、定番の CORA データセットでの検証結果が紹介されています。
シンプルな GCN だと、だいたい二層くらいで精度が一番よくて、そこから層数を増やすと MADGap が下がっていくのと同時に、精度も崩壊していったと。
一方で、DropEdge と残差結合を組み合わせると、十層から二十層くらいまで深くしても、精度低下がかなり緩和された、という結果が示されています。
記事の結論としては、「多層 G N N を設計するときには、データセットの同質性・異質性をちゃんと見極めたうえで、MAD や MADGap、Effective Rank といった診断指標をチェックしながら、グラフ構造の調整とアーキテクチャの工夫を組み合わせるのが大事だ」というまとめでした。
グラフ系を実務で使っている人には、実験結果込みで参考になる内容だと思います。
。。。。
そして五つ目。
最後はちょっとライトに、C プラスプラスの独特な Hello World の書き方を題材に、演算子オーバーロードという仕組みを Python で真似しながら理解していく Tips 記事です。
C プラスプラスの「エスティーディーシーアウト シフトシフト ダブルクォートハローダブルクォート」というおなじみの書き方、ありますよね。
ここで使われている「小なり小なり」、本来はビットシフト演算子なんですが、C プラスプラスでは「演算子オーバーロード」という仕組みを使って、その意味を「出力用の記法」に上書きしているんだよ、という解説から始まります。
演算子オーバーロードって何かというと、ユーザーが定義したクラスに対して、「足し算のプラス」や「小なり小なり」みたいな既存の演算子の動きを、自分で決め直せる仕組みのことです。
C プラスプラスでは、ストリーム出力のためにこの「小なり小なり」をオーバーロードして、左側にストリーム、右側に出したい値を置くと、そのまま出力されるようにしています。
この記事では、それを Python で真似てみよう、ということで、クラスに「ダブルアンダースコア エルシフト ダブルアンダースコア」、いわゆるエルシフトの特殊メソッドを実装して、Python 上でも「シーアウト シフトシフト 四十二 シフトシフト エンドエル」みたいな C プラスプラス風コードを再現してみせています。
こうやって実際に手を動かしてみることで、「あ、こうやって演算子の意味を上書きしてるのか」と、仕組みが直感的に理解できるようになっているわけですね。
ただ、この C プラスプラスのストリーム式出力には、「国際化対応がしづらい」とか、「テンプレートが絡んでコンパイルが遅くなる」とか、いろいろと批判や反省点もあります。
その結果、他の言語にはあまり広まらなかったし、C プラスプラス界隈の中でも“ちょっと扱いづらいよね”という空気があると紹介されています。
そうした反省から、C プラスプラス二十三では「エスティーディープリント」が導入されました。
「エスティーディープリント ダブルクォート波括弧波括弧バックスラッシュエヌダブルクォート カンマ 四十二 セミコロン」みたいな感じで、他言語のプリントエフやフォーマットに近い、より直感的な書き方ができるようになっていて、今後はこちらが推奨されていく流れだと、記事ではまとめられています。
つまり、昔ながらの「シフトシフト」でおなじみの Hello World からスタートして、
「演算子オーバーロードってこういう仕組みなんだね」
「Python でも似たことができるんだね」
「でもその書き方にもいろいろ課題があって、新しいプリントスタイルが出てきたんだね」と、言語仕様の歴史と設計思想まで見えてくる、読み物としても楽しい記事でした。
。。。。
というわけで、きょうの「zenncast」、お届けしてきた内容を駆け足でおさらいしていきます。
まずは、AI に大部分を書かせたコードを半年運用した経験から、「コメントは“なぜ”だけ書く」「小さな責務に分割する」「仕様とテストは人間が握る」といった、“引き算”で保守性を守るコツのお話。
次に、Claude Fable Five を期間限定の“超優秀な手順書職人”として使い倒して、Agent SOP で Markdown の SOP からスキルや MCP プロンプトを自動生成しつつ、実際のやらかしログを理由付きの Constraints に落としていくという、ナレッジ資産づくりの話。
三つ目は、Fable Five・Opus・Sonnet など複数モデルをチームとして設計して、「考える」「設計する」「実装する」「テストする」を細かく分担し、ccteams という CLI でそのチーム構成とオーケストレーションルールを一撃で生成する運用 Tips。
四つ目は、G N N の代表モデルと、オーバースムージング問題。
MAD、MADGap、Effective Rank みたいな診断指標を使いつつ、DropEdge や AdaEdge、残差結合や GCNII などで深い層でも表現の多様性を保つ設計が大事だよ、というグラフニューラルネットの実践知。
そして最後に、C プラスプラスの「シフトシフト Hello World」から、演算子オーバーロードを Python で真似しつつ理解していく話と、その反省から生まれた C プラスプラス二十三の「エスティーディープリント」まで、言語デザインの歴史をのぞき見するような記事をご紹介しました。
それぞれの詳しい内容や、元の記事へのリンクはショーノートにまとめてありますので、気になったトピックがあった方は、ぜひあとでじっくり読んでみてください。
「zenncast」では、番組の感想や、取り上げてほしいテーマ、AI との付き合い方の悩みごとなんかも、どしどし募集しています。
「こういう記事を深掘りしてほしい」「このツールの実践例が知りたい」などありましたら、ぜひお便りフォームから送ってください。
ということで、きょうのお相手はマイクでした。
次回も、この時間にお会いできるのを楽しみにしています。
それでは、みなさん今日も良い一日を。バイバイ。