どうもー、おはようございます。マイクです。
朝七時を少し回ったところ、二千二十六年八月十日、月曜日の朝です。
ここからの時間は「zenncast」。きょうも、技術者のみなさんの朝コーヒーのお供に、Zennで話題になっているトレンド記事をゆるっと、でも中身はしっかりめにご紹介していきます。

きょうはお便りコーナーはお休みで、そのぶんガッツリと記事を掘り下げていきたいと思います。
紹介する記事はぜんぶで五本。どれも「AI」「エージェント」「開発環境」「Cシャープ」「お金まわりのインフラ」と、バラエティに富みつつも、ちゃんとつながりを感じるラインナップになっています。

それじゃあ、さっそく一つ目からいきましょう。

。。。。

まず一つ目は、社内ナレッジ検索の実例として、Cerebrasが構築した「Cerebras Knowledge」を紹介している記事です。
背景にあるのが、エンジニアのみなさんも身に覚えがあるんじゃないでしょうか。Slack、GitHub、Jira…と、社内の情報がいろんなツールにバラバラに散らばっちゃっていて、とくにチャットの会話は、そのままだと検索にめちゃくちゃ弱い、という問題ですね。

この記事の面白いところは、「じゃあベクトルデータベースをドカンと用意しました！」じゃないんですよ。
Cerebrasは、あえて専用のベクトルDBを使わずに、PostgreSQLだけで全文検索とベクトル検索を両立させています。インフラ構成を、とことんシンプルに寄せているんですね。

Slackのスレッドも、そのままをベタッと埋め込むんじゃなくて、いったんLLMで「質問文」や要約などの構造化データに変換します。さらに、長い連投の中から重要な発言だけを条件付きで別チャンクに切り出すことで、検索の精度をグッと上げている、という工夫も紹介されています。

検索するときは、キーワード検索と意味検索、それからレアな単語を重く見る重み付け、そして更新日の新しさ、この四つを組み合わせてスコアリングして、最後に小さいモデルで再ランキングする、という多段構成です。
ここまでやると、「なんとなくの類似」と「ちゃんと今っぽい情報」をバランスよく拾えるわけですね。

もう一つポイントなのが、人間が使うUIと、AIエージェントが使うインターフェースをちゃんと分けているところです。
エージェント向けにはMCPという枠組みの中で、`search_slack`みたいなシンプルな検索部品だけをツールとして公開して、どのツールをどう組み合わせて使うかはエージェント側に任せる、という設計になっています。
「全部自前でワンストップにしないで、部品として提供する」という姿勢ですね。

一方で課題もあって、全データを自前のデータベースに集約するぶん、アクセス権限の管理がかなり難しい。さらに、用途ごとにAIエージェントを分けたくなったときも、この権限設計がボトルネックになりがちだ、と指摘しています。

全体としては、「RAGで社内ナレッジ検索やりたい！」という理想論ではなくて、実際に運用レベルで回っているシンプルな実装例として、とても参考になる内容になっています。
社内検索をどう整えるか悩んでいる方には、発想のヒントがかなり詰まっている記事ですね。

。。。。

続いて二つ目。こちらは、Claude Code を使って、AIエージェントが自律的にバグ検知から修正までを繰り返す「ループエンジニアリング」を、本当に組んでみた実験記録をまとめた記事です。

ここでやっているのは、単なる「AIを一回呼び出すだけのバッチ処理」とはぜんぜん違います。
AI自身が、「何を直すか」「どう直すか」「直ったと判断するか」を、ずっと自分で決め続ける仕組みをつくっています。

構成としては、Maker と Checker という役割を分けていて、Makerが実装役、Checkerが検証役です。
Checkerには書き込み権限を与えず、pytestやmypyといった自動テストを、AIが言い逃れできないゲートとして必ず挟むことで、「自己採点が甘くなる問題」を防いでいます。

検証フェーズでは、Cloud Loggingのエラーログをもとに、「想定内の異常、たとえばユーザーの入力ミス」と、「本物のバグ」をちゃんと分けるステップを明示的に入れています。
これによって、「正常なバリデーションエラーを、ずっと頑張って修正しようとしてしまう」という無駄なループを避けつつ、実際にあった、「全角数字を半角として誤判定してしまうバグ」を、仕様書との食い違いからちゃんと検出して、修正することができたそうです。

さらに面白いのが、Maker と Checker を別コンテキストで動かしている点です。
Checker側は、ログの取得、コードの確認、APIの実行、テストの実行を、毎回一からやり直すことで、「他人にガチでコードレビューされている」のに近い検証が、自動でぐるぐる回るのを確認しています。

ここから筆者が得た教訓として強調しているのは、「直すこと」よりも、「そもそも本当に直すべきかどうかの判定」のほうが重要、という点です。
そのためには、権限をぎゅっと絞ったサブエージェントを用意したり、毎回フレッシュなコンテキストで検証をやり直したりする設計が、信頼できる自動化には欠かせない、と述べています。

今後の展望としては、今は単一プロジェクト専用になっているこの仕組みを、サービス名とリポジトリを結びつけるレジストリを用意することで、複数プロジェクトに広げたい。さらに、プルリクエストの作成や定期実行まで含めて、運用レベルの自動化に発展させていきたい、としています。
「自動バグ修正ボットをちゃんと現場に入れるには？」というリアルな視点が詰まった記事です。

。。。。

三つ目の記事は、ハード好きな方にも刺さりそうな内容。
Raspberry Pi ファイブに NixOS を入れて、Claude Code を常時起動させて、どこからでもアクセスできる開発エージェント環境を作る手順を、ていねいに解説している記事です。

狙いとしては、Macなどの手元マシンだとスリープして止まりがちなので、低消費電力で二十四時間動かせるラズパイを、専用のサーバとして使おう、という発想です。

NixOSでは、flakeという仕組みで構成をコード化していきます。
この記事では、`flake.nix`と、複数のモジュールを組み合わせて、SDカード向けのイメージを自動生成します。Docker上のLinuxビルダーを使って、アーム六十四ビット、つまり`aarch64`向けのイメージをビルドして、MacからSDカードに書き込んで起動。そのあと、SSHの公開鍵でログインする、という一連の流れが紹介されています。

起動後の運用面も工夫されていて、GitHubのリポジトリをブート時に自動でクローンしたり、プルしたりするサービスを用意したり、`claude remote-control`をsystemdのサービスとして常駐させたりします。
さらに、`go-task`のTaskfileを使って、`task start`みたいな簡単なコマンドで、サービスの起動や停止を制御できるようにもしてあります。

Raspberry Pi ファイブ特有のハマりどころも、かなり具体的に書かれています。
たとえば、ベンダーが提供しているカーネルとデバイスツリーを使わないと、そもそも起動しなかったり、ファンの制御が壊れたりする、といった問題があるそうです。
また、時計の同期がずれているとTLS、つまり暗号化通信が失敗してしまうので、起動前に時刻同期を待つようにする、といった工夫も必要とのことです。

最終的には、GitHubとAWSの権限をきっちり絞ったうえで、Claudeにコード生成や、CDK経由のAWS更新まで任せられる、「常時利用可能なAIエージェント環境」が出来上がります。
「家に小さなAI開発サーバを一台置いておく」みたいな世界観が、かなり現実的な手順で示されている記事ですね。

。。。。

四つ目は、Cシャープ好きには気になる話題。
Cシャープ十五で入ってくる`union`型と`closed`修飾子を使って、依存性注入で受け付ける実装クラスを、AとBとCなど、あらかじめ決めた数個だけにきっちり制限できるよ、という記事です。

これまでの`interface`ベースのDIは、柔軟な反面、ライブラリの利用者が好きな実装をいくらでも差し込めてしまう、という問題がありました。
「変な実装を渡されると、ライブラリ側で想定外の動きになるかもしれない」という不安が残るんですね。

この記事では、その課題に対して、「テストではinterface経由で自由にフェイク実装を注入しつつ、公開APIではunionで選択肢を固定する」というパターンを紹介しています。

具体的には、内部コンストラクタでは`IClock`を受け取るようにしておいて、公開コンストラクタでは、`ClockProvider`のような`union`型だけを受け付けます。
さらに、`InternalsVisibleTo`を設定して、テストプロジェクトからはinternalコンストラクタとフェイク実装にアクセスできる構成にしておきます。

こうすることで、実運用の場面では、型として受け入れられる実装の範囲を厳しくコントロールしつつ、テストコード側では、テストダブルを柔軟に差し替えられる状態を保てます。
つまり、「制約の強い、安心な公開API」と、「テストのしやすさ」を同時に両立できる、というわけですね。

ライブラリやSDKを提供する立場の人にとっては、「使ってほしい実装だけを安全に選ばせる」ための、新しい武器になりそうな内容です。

。。。。

そして五つ目。
こちらは少しマクロな視点で、Cloudflare Wallets と cloudflare.pay の発表をどう捉えるか、という記事です。
「決済サービス出しました」という話に見えるんですが、実はもっと深いところを狙っているんじゃないか、という分析になっています。

Cloudflareは、このサービスを、Coinbaseのx四〇二という共通の決済レールの上に乗せています。
つまり、自分たちの中だけで通貨やレールを囲い込むというよりは、標準化された決済レールと、Web Bot Authのような身元認証の仕組みを土台にして、その「外側」を自社製品として押さえにいっている、という構図です。

具体的には、「名前空間」と「支出の認可点」です。
cloudflare.payは、エージェントの公開鍵に、人間が読めるハンドル名を対応させる、DNSのような仕組みとして出てきました。
ただ現状では、中央集権的で、先着順で、いったん取った名前は実質的に恒久、という設計になっていて、なりすましやブランド占拠のリスクも、すでに見え始めています。

一方で、競合するオンチェーン型の身元レジストリとして、ERC八〇〇四という仕組みもあります。
こちらは「誰も信用しない」という前提で設計されていて、どちらが最終的に普及するかは、理念のきれいさよりも、実際にどれくらいトラフィックが流れるかで決まりやすい、という指摘もされています。

CoboやMetaMask、CoinbaseのCDP Agentic Walletsなど、ほかのプレイヤーも、支払いの上限や許可リストを、モデルの外側で強制するという点では同じ路線にいます。
ただ、「どこで止めるか」がそれぞれ違う。秘密鍵の署名レベルでストップするのか、人間の確認に戻すのか、オンチェーンの制御コントラクトで弾くのかによって、安全性も性質も変わってきます。

Cloudflareは、この「認可点」を押さえに来ているわりに、その仕組みの詳細をまだあまり公開していません。
その結果、最も重要な「どこで強制がかかるのか」がよく分からないまま、「名前空間だけが先に市場を押さえ始めている」という、ちょっと危うい状況と、それでも大きなチャンスが同時に存在している、と記事では指摘しています。
AIエージェントがお金を動かす世界に向けて、「誰がブレーキペダルを握るのか？」という、かなり根本的な問いを投げかける内容になっています。

。。。。

というわけで、きょうのzenncast、五本のお話を駆け足でおさらいしていきましょう。

まず一つ目は、CerebrasがPostgreSQLだけで全文検索とベクトル検索を両立させた「Cerebras Knowledge」。Slackの会話をLLMでうまく構造化しつつ、シンプルな構成で社内ナレッジ検索を回している事例でした。

二つ目は、Claude Codeを使って、AIが自律的にバグ検知から修正までをぐるぐる回す「ループエンジニアリング」の実験。MakerとCheckerを分けて、テストを厳格なゲートにすることで、信頼できる自動化に近づけているという話でした。

三つ目は、Raspberry PiファイブにNixOSを入れて、Claude Codeの常時稼働エージェント環境を作る手順。flakeベースの構成管理や、ラズパイ特有のハマりポイントも押さえた、実践的なセットアップガイドでした。

四つ目は、Cシャープ十五の`union`型と`closed`修飾子を使って、公開APIで受け入れる実装クラスをきっちり制限しつつ、テストでは柔軟なDIを維持するパターン。堅いAPIとテスト容易性を両立する設計の話ですね。

そして五つ目は、Cloudflare Wallets / cloudflare.payを、「エージェントのお金の出入りをどこでどう制御するか」という主導権争いの文脈で捉えた記事。名前空間と認可点をめぐる、各社の戦略とリスクが整理されていました。

それぞれの詳しい内容や、元の記事へのリンクは、この番組のショーノートにまとめておきますので、気になったトピックがあれば、あとでじっくり読んでみてください。

この番組「zenncast」では、みなさんからの感想や、「こんなテーマを取り上げてほしい」といったリクエストもお待ちしています。
「社内でこんなふうにAIエージェント動かしてるよ」とか、「Raspberry PiとNixOSやってみた」みたいな実践ネタも、ぜひ教えてください。

それでは、きょうはこのへんで。
お相手はマイクでした。次回のzenncastで、またお会いしましょう。
いってらっしゃい、良い一日を！