どうもマイクです。おはようございます。
二千二十六年七月三十一日、金曜日の朝七時を回りました。ここからの時間は「zenncast」、きょうもZennで話題になっているトレンド記事を、ゆるっと楽しく紹介していきます。
きょうはお便りはお休みなので、そのぶんガッツリと記事を見ていきましょう。
きょう紹介する記事は全部で五本です。技術仕様の大きなアップデートから、AIエージェント時代のCIコスト、リリース前チェックの仕組み作り、AIがブラウザを操作する話、そして個人用ナレッジベースの作り方まで、かなり盛りだくさんです。
では一つ目。
まずはMCPの二千二十六年七月二十八日版の仕様変更についての記事です。これは、従来の「セッション前提」の設計をガラッと見直して、各リクエストが一回で完結する、いわゆるステートレスなモデルに大転換しましたよ、という話ですね。
具体的には、これまであった`initialize`みたいなハンドシェイクと、`Mcp-Session-Id`といったセッションIDの仕組みが廃止されています。その代わりに、「状態が必要な処理」はサーバー側がハンドルや`requestState`を返して、それをクライアントが持ち回る形に変わった、というのがポイントです。
つまり、サーバー側にはなるべく状態を持たせず、必要なコンテキストはクライアント側が握ることで、スケールさせやすくしているイメージですね。
もう一つ大きいのが、ユーザー確認を挟むような、いわゆる対話的な処理の扱い方です。これまではSSEで長時間つなぎっぱなしにして対話する、みたいな作りも多かったんですが、新しい仕様では、`input_required`と`requestState`を使った「マルチラウンドトリップ・リクエスト」で表現します。
これによって、同じ処理を、サーバーのインスタンスをまたいでも継続できるようになっていて、「一台のサーバーに張り付き続けないと完走できない」という制約がかなり減ります。
合わせて、RootsとかSampling、Logging、それからレガシーなHTTPプラスSSEのやり方は非推奨になりました。ただし、いきなり打ち切りではなくて、少なくとも十二か月は使えることが明示されているので、移行期間はちゃんと確保されている形ですね。
認可まわりもけっこう手が入っていて、トークンのissuer検証が強化されたり、Dynamic Client RegistrationからCIMDという仕組みへの移行が進んだりと、全体的に「安全側に倒す」方向の変更が入っています。
この新仕様自体はTypeScriptのSDK、バージョン二に実装されていて、このバージョン二のサーバーは、新しいクライアントも、従来のクライアントも、両方受け付けられるようになっています。つまり、サーバー側を先にアップデートしておいて、クライアントを少しずつ移行していける、移行しやすい構成になっている、というのが嬉しいところです。
セッション前提の設計から、ステートレス前提に切り替えていく流れに関心がある人には、細かい挙動まで丁寧に追える記事になっていますよ。 。。。
続いて二つ目。
AIエージェントがたくさんプルリクエストを出すようになってきて、「気づいたらGitHub Actionsの実行回数も、一回あたりの処理時間も増えまくってるんだけど…」という、CIコストの悩みを題材にした記事です。
筆者のチームでは、まずGitHubの標準ランナーから、Blacksmithというサービスに移行しました。狙いは、同じくらいの支払いで、より大きいマシンを使えるようにして、一回あたりのCIのコストを下げること。その結果として、CI一回あたりのコストをおよそ四十五パーセント削減できた、と書かれています。
ところがこのBlacksmith、運用していると、ときどき`npm install`に相当する処理が、ログを出さないまま黙って止まってしまい、CIが何時間も終わらない、という問題に悩まされます。そこで、今度はNamespaceという別サービスに再度乗り換えました。
Namespaceに移ったところ、テスト時間のばらつきが減って、「たまに止まる」というトラブルもかなり減り、しかもトータルのCIコストも、GitHubのホステッドランナー時代の、およそ四分の一になった、と報告されています。かなりインパクトありますよね。
一方でNamespaceには、プランごとに「同時に使えるCPU数の上限」と「月額の固定費」があるので、移行前に自分たちのピーク時の同時実行数をきちんと測っておかないと、CIが詰まってしまって、結局ロールバックするリスクもあると説明しています。
まとめとしては、無料枠に収まっているチームであれば、GitHub hostedのままでまったく問題ないし、無料枠を超えはじめたら、BlacksmithやNamespaceのような選択肢を試してみるといい、というスタンスです。
特に、AIエージェントがプルリクを大量に出して、CIの並列度が高くなっているような環境では、「一部のジョブだけめちゃくちゃ遅い」といったレイテンシのテールと、全体の安定性を重視してプラットフォームを選ぶべきだ、と結論づけています。コストだけじゃなくて、止まりにくさやバラつきの少なさも、もはや重要な設計要素なんだ、というのがよく伝わる記事です。 。。。
三つ目いきましょう。
ここからは「プロダクトリリースハーネス」と呼んでいる、開発中プロダクトのリリース前チェックをAIに手伝ってもらう仕組みづくりの話です。内容としては、実装というよりはTips集に近くて、「どうやってAIにリリースチェックを任せるか」のノウハウがまとまっています。
まずやるのは、AIに対して「リリース前にチェックすべき項目を、できるだけ網羅的に出して」とお願いするところから。ここで出てきた大量のチェック項目を、そのまま全部採用するのではなくて、「これが満たせないなら本当にリリースを止めるのか？」という観点で七割くらい削っていきます。
そうやって絞り込んだ結果として、およそ百項目から成る、“正本”チェックリストを作る。各項目には、「なぜこのチェックが重要なのか」「どこを見れば確認できるのか」「具体的に何をするのか」「合否の判定ルールは何か」をきちんと書き込みます。
このリストをGitで管理して、人間側もAI側も、同じリストを見て話せるようにする、というのが一つ目のポイントです。
次に、そのチェックリストとリポジトリ全体のコードを、AIに読ませます。そして各項目について、「パス」「フェイル」「要確認」「未検証」「対象外」という、五種類の区分で判定させる設計になっています。
ここで大事なのは、「見つからなかったからフェイル」とはしないこと。情報が見つからないものは「未検証」として扱い、実際にリリースを止める対象は、必須項目のフェイルだけに絞る。これによって、「AIが見つけられなかっただけなのに、リリース全体が止まる」といった事態を避けています。
また、「コードだけでは判断できない項目」もたくさんありますよね。そういったものは、あらかじめ決めておいた場所、たとえばインフラの定義用リポジトリとか、法務のSlackチャンネル、運用ドキュメントなどから、AIに証跡を探しに行かせます。
そこで事実関係だけで判定できるものは「パス」に、法務判断など人の判断が絡むものは「要確認」に格上げして、「未検証」のまま終わるものをできるだけ減らしていく、という工夫もされています。
最後に、スキャンの結果は一か所に集約します。具体的には、Pull Requestとしてまとめてしまって、その中に「フェイル」「要確認」「未検証」の一覧と、その根拠、そして誰が何を確認するのか、最終的なGo・ノーゴーの判断をどう記録するのか、といった情報を書き残していきます。
これを社内のすべてのプロダクトで回すことで、チェックリスト自体がどんどん改善・増補されていきます。その過程で、社内の専門家たちの観点が、形式知として蓄積されて、より多くのプロダクトに行き渡る仕組みになる、というのがこの記事の肝ですね。
「AIに丸投げ」ではなく、「AIと人間が同じチェックリストを共有して、役割分担しながらリリースの品質を上げていく」、そんなイメージを持てる内容になっています。 。。。
四つ目。
今度は、AIがブラウザを操作する技術の話題です。agent-browserのようなツールで、「とりあえずどんな画面でも、その場でAIがクリックして入力して操作できるよ」というところまでは、すでにだいぶできるようになりましたよね。
この記事では、その先の話として、「一度のWeb調査で得た知識を、次回も使える形でちゃんと残すこと」が重要になってきている、と説明しています。
具体例として取り上げられているのが、OpenCLIというツールです。OpenCLIは、ChromeをAIから操作する機能と、その操作を通じて分かった「このサイトからこうやってデータを取れるよ」という取得方法を、「アダプター」として登録できる仕組みを統合しています。
そうすると、「ツイッターのブックマークを取ってきて」といった操作を、そのまま`opencli twitter bookmarks`みたいな、サイト専用のコマンドとして呼び出せるようになる。これがOpenCLIの特徴だと紹介されています。
一方で、ほかのツールも、それぞれ「何を成果物として再利用するか」が違っています。
agent-browserとderive-clientの組み合わせでは、内部APIクライアントを残す形になりますし、Webwrightというツールでは、Playwrightのコードとして操作手順を残す、というスタイルになっています。
つまり、「同じサイトから繰り返し情報を取りに行けば行くほど、CLIなのか、アダプターなのか、コードなのか、どの形で知識を蓄積するかが効いてくる」という整理ですね。用途に応じて、どの形が一番メンテしやすいのかを選ぶ必要がある、と指摘されています。
また記事の後半では、「サイゼリヤCLI」の議論にも触れながら、通信の解析やブラウザ操作の自動化といった技術は、すでに広く行われているのだ、という視点が示されています。
個別の事例だけを切り取って「これは良い、これはダメ」と反応するのではなくて、この種の技術全体について、一貫した倫理の議論が必要だ、という締めくくり方をしているのも印象的でした。技術として「できること」と「やってよいこと」の線引きを、どう考えるか。開発者に問いかける内容になっています。 。。。
そして五つ目、最後の記事です。
PKB、いわゆるパーソナル・ナレッジ・ベースをどうやって構築して、日々運用していくかをまとめた記事で、テンプレートを使うことで、ObsidianのVaultを「人間とAIの共通メモ帳」にする方法が詳しく紹介されています。
予定やメール、Slackのメッセージなどを自動的に集約して、一枚のデイリーノートで全体をさばく仕組みを、ほぼノーコードで立ち上げられるのが売りになっています。
大きな流れは三段階。
まず第一に、ChatGPTアプリの導入と、Codex CLI、それからObsidianとClaudianプラグインのセットアップを行います。ここでAIとの接続基盤と、メモ帳であるObsidianの連携環境を整えるイメージですね。
第二に、PKB用のテンプレートをObsidianのVaultにクローンします。そしてPersonaノートという専用のノートに、自分のプロフィールや好みの文体、どんな風にサポートしてほしいか、といった情報を書き込んでいきます。
これによって、AIが「このVaultの持ち主がどんな人か」を理解しやすくなり、やり取りの精度が上がっていく、という狙いがあります。
第三に、Hermes Agentというエージェント基盤を導入して、このVaultをホームベースとして外部連携の土台を作ります。そのうえで、GoogleカレンダーやGoogleタスク、Gmail、Slackといった外部サービスを、OAuthなどの認証を使って、Hermesに順番に接続していきます。
これで、予定・タスク・メール・チャットが、共通のVaultに自動で流れ込んでくる状態が整います。
運用面の話もとても具体的で、まず朝には「briefing」として、その日の予定やタスクを自動的に集約して確認する時間を取る。日中はSlackやメールなどをInboxに取り込みつつ、Dailyノートにどんどん集約していく。
そして夜には、その日に溜まった情報をWikiへ「蒸留」していく振り返りタイムを設ける、という日次ループが提案されています。単なる「情報の山」になりがちなInboxを、ちゃんと知識として整理していく習慣づけですね。
記事では、認証エラーが起こったときの対処や、Inboxに情報が多すぎて処理しきれないときの工夫など、いわゆる「詰まりどころ」にも触れています。
そのうえで、「テンプレートで土台を共有することで、個人ごとのPKBづくりは、認証設定と、日々の運用の工夫に集中して育てていける」という考え方が示されています。同じ土台からスタートして、それぞれが自分の生活スタイルに合わせて育てていく、そんなPKBのイメージがつかめる内容でした。
というわけで、きょうの「zenncast」、お送りしてきました。
ざっとおさらいすると、まずはMCPがセッション前提からステートレスなモデルへ大転換した話。次に、AIエージェント時代のCIコストを、BlacksmithやNamespaceを使ってどう最適化するかという話。
三つ目は、AIにリリース前チェックを手伝ってもらう「プロダクトリリースハーネス」の作り方。四つ目は、AIがブラウザを操作するだけでなく、調査結果をどう再利用可能な形で残すかという整理と、倫理の話。
そして最後に、Obsidianとエージェントを組み合わせて、PKBを人間とAIの共通メモ帳として育てていくための手順と運用Tipsをご紹介しました。
気になる記事があれば、詳しい内容はショーノートにリンクをまとめておきますので、ぜひそちらから元の記事も読んでみてください。
番組の感想や、「こんなテーマを扱ってほしい」といったリクエストも、どしどしお待ちしています。
それでは、きょうも良い一日をお過ごしください。
お相手はマイクでした。また次回の「zenncast」でお会いしましょう。