おはようございます。マイクです。
「zenncast」第……何回目かはさておき、2026年5月10日、日曜日の朝7時をまわりました。
この番組では、Zennでいまトレンドになっている技術記事やナレッジを、ラジオ感覚でゆるっと紹介していきます。
今日はリスナーのみなさんからのお便りはお休み、ということで、そのぶんガッツリと記事を紹介していきますね。
さて、今日紹介する記事は全部で5本。
テーマとしては「Claude Code」「AIエージェント」「開発ルール」「DB設計」あたりがっつり、という感じです。それぞれ、手元で作業しながら聞いてもイメージしやすいようにお話ししていきます。
まず1本目。
タイトルは「あなたの Claude Code、実は前回のセッションを完全に忘れている（5 分で永続記憶を入れる）」という記事です。
Claude Codeって、エディタ上で会話しながら開発できて便利なんですけど、実はセッションをまたいだ「記憶」を設計上ほとんど持っていません。昨日めちゃくちゃ苦労してデバッグしたポイントとか、「なぜその設計にしたのか」という理由、そして特に痛い「やらかし」や教訓が、セッションを閉じた瞬間に、きれいさっぱり忘れられてしまうんですね。
この記事では、その問題を「MCP server」という仕組みで解決しよう、という提案をしています。登場するのが「Linksee Memory」というサーバー。ローカルのSQLiteに、goal・context・emotion・implementation・caveat・learning という6つの層で記録していきます。なかでもポイントは「caveat」層。ここが「二度と同じミスをさせないための教訓」フォルダになっていて、自動では消えないようになっている。つまり、一度痛い目にあったら、次のセッションでもClaudeにちゃんと覚えておいてもらえる、というわけです。
導入も5分くらいでできるように設計されていて、Node.jsが入っているか確認して、`claude mcp add` でサーバーを登録して、専用のSkillを入れて、Claude Codeを再起動して動作確認、という流れ。ポイントは、Skillを入れないとClaudeが自動で「recall」「remember」を使ってくれないので、そこはちゃんとセットで入れようね、という注意点。それから、セッション終了時の `Stop` フックで自動同期を仕込んでおくと、毎回手動でメモを取らなくても済むよ、という工夫も紹介されています。
面白いのが、この永続メモリはClaude Code専用ではなく、CursorやOpenAI系、Gemini CLIとも共有できる、というところ。つまり「自分の開発エージェントたちが共通の記憶を持つ」状態にできる。自分とAIのチームに、ちゃんと一貫した「学習」がたまっていくイメージですね。AIとの開発で「同じ説明を何回もしているな」と感じている人には、かなり刺さる内容だと思います。
。。。。
続いて2本目。
タイトルは「Claude Codeの失敗をチームルールに昇格させる仕組み」という記事です。
さっきの1本目は「個々のセッションの記憶」を残そう、という話でしたが、こちらはもう一歩進んで、「失敗をチームのルールに育てていく」話です。筆者はClaude Codeで3エージェント構成のハーネスを使っていて、その中で起きた失敗を、次回以降に確実に活かせるようにするための仕組みを作っています。
キーワードは3つ。「FAILURES.md」「/failure-promote」「/retro」。
まず、Evaluatorエージェントが「NEEDS_REVISION」とか「GENERATOR_FAILED」を出したとき、そのときの failed_checks と required_fixes を、自分のローカルにある FAILURES.md にどんどん追記していきます。これが「個人のやらかしログ」。ただし、それが1回2回出たくらいでは、いきなりチームルールにはしない。ここがけっこう人間ぽい設計で、同じパターンが3件以上たまったときだけ、「これはもう組織としてのルールにしよう」と昇格候補にするわけです。
そこで使うのが /failure-promote というコマンド。FAILURES.mdから似た失敗をまとめて、「chunkの種類ごとのrules」や、プロジェクトに置いてある CLAUDE.md に追記するルール案、PRの雛形などを自動生成します。つまり、「なんとなくこうしたほうがいいよね」と口頭で終わりがちな学びを、ちゃんとリポジトリのルールに落とし込む仕組みになっている。
さらに /retro コマンドでは、コミット履歴やPRコメント、手でやった修正なんかを眺めて、そこから学びを自動抽出します。「コードスタイル」「アーキテクチャ違反」「ドメイン知識不足」「外部連携ミス」「危険操作」といったカテゴリに分けて、どれを急いで直すか、「今すぐ対応」「次のPRで」「とりあえずTIL」といった優先度まで付けてくれる。で、その結果をメモリやrules、Hookに反映させることで、「失敗→ルール→ハーネス更新」というループを閉じにいきます。
前提としては、Safety Hookとか、chunk分解といった品質ゲートがある程度整っていることが必要、とも書かれていますが、「AIの失敗を、ちゃんとチームの成長に変える」考え方として、とても参考になる記事でした。
。。。。
3本目。
タイトルは「Claude Codeを"使いこなす"ための個人ルール設定 - 実際にやって効果が高かった設定」です。
これはさっきまでの「チーム」「ハーネス」という話より、もっと身近な「自分がClaude Codeにどう振る舞ってほしいか」を決める、パーソナルチューニングの話です。
テーマは、「同じ指示を何度も書いたり、無駄な前置きでログが埋まったりする時間を減らそう」というもの。そこで登場するのが、個人用の CLAUDE.md と settings.json です。筆者は、あれこれルールを詰め込むのではなく、「短い」「いろんな動作に効いてくる」という2つの条件を満たすルールに絞るのがコツだと書いています。
たとえば1つ目が、回答スタイルのルール。「挨拶や社交辞令は不要」「結論ファーストで話す」「必要なときだけ補足を書く」といったもの。これを先に決めておくと、「もっと短く」「前置きいらないです」と毎回指示しなくて済む。
2つ目はブランチ運用のルール。例えば「作業前にdevelopを最新にしてからブランチを切る」「pushの条件」「不要ブランチの削除提案」までをまとめておく。Claudeに「このリポジトリでの正しい開発フロー」を覚えさせる感じですね。
3つ目はプロジェクト固有の手順。サブモジュール反映の手順とか、自分の環境特有のビルドコマンドとか、「毎回口で説明していること」をルール化しておく。
4つ目がコード説明ルール。コードを変更したら、「意図」と「差分」を毎回説明させるようにしておくと、後から読むときにすごく楽になる、という話です。
さらに settings.json 側では、ステータスラインにモデル名やコンテキスト、コストを表示するカスタマイズも紹介されています。どのくらいトークンを使っているか、今どのモデルなのかが常に見えるので、「なんか最近重いな……」みたいなモヤモヤを減らせる。加えて、自動Compactionの閾値を60％くらいまで下げておく設定もおすすめされていて、長いセッションで履歴が削られすぎて精度が落ちる、というのを防ぎやすくなります。
まとめとして、「自分が毎回やっている作業」をルールとして明文化しておくだけで、指示の重複が減り、読むログも減り、出力精度やレビュー速度まで上がるよ、という内容でした。Claude Codeを日常的に使っている人には、すぐ真似できそうなテクニックが多い記事です。
。。。。
さあ、4本目。
タイトルは「AIエージェント時代のDB設計をTursoが書き換えに来ている話」です。
これはちょっと視点が変わって、データベースの話。従来のPostgreSQLやMySQLでは、1つのDBインスタンスそのものが「高価なリソース」でしたよね。なのでSaaSをマルチテナントで作るときは、どうしても「共有DB＋tenant_idを付ける」とか、「スキーマ分離する」とか、Row Level Securityを駆使するとか、そういう方向に寄りがちでした。「テナントごとに物理DBを分ける」は、コスト的にも運用的にもなかなか厳しかった。
一方でSQLiteは、「DB=ただのファイル」という超軽量な世界。でも、単一ライター制約があったり、「外部の人が書き換える前提」にしづらかったりと、構造的な限界もあった。
そこで出てくるのがTurso。SQLiteフォークのlibSQLからスタートして、それをRustでほぼ書き直しつつ、非同期I/OやWASM実行、ベクトル検索、MVCCベースの並行制御などを取り込んで、「SQLiteっぽいのに、単一ライター制約を超えていけるDB」を目指しています。
技術的な工夫もおもしろいんですが、この記事で特にインパクトとして語られているのは料金モデルです。Tursoは「アクティブDB数課金」をやめて、「ほぼ無制限にDBを作っていいよ」という方向に振ってきている。これによって、「テナント＝DB」「エージェントやセッション＝DB」といった、物理的に分ける設計が現実味を帯びてきた、と。
結果として、「DBは高級な共用リソース」ではなく、「コード中の変数みたいに、必要なだけポンポン作るもの」として扱える世界観が見えてきます。AIエージェントがユーザーごと・タスクごとに違うデータを持つようなサービスや、ノーコード／アプリビルダー系のSaaSなどで、「データの分離をどうするか？」という発想そのものを変えうる動きだ、と筆者は評価しています。エージェント時代のインフラを考えるうえで、押さえておきたい記事ですね。
。。。。
最後、5本目。
タイトルは「Anthropic の 5 パターンで Claude Code エージェント設計を分類する」です。
これは、Anthropicが公式で出している「マルチエージェント協調パターン5種類」を、Claude Codeでどう実装し、どう選び分けるかを整理した記事です。5つのパターンは、
Generator-Verifier、Orchestrator-Subagent、Agent Teams、Message Bus、Shared State。
この記事ではまず、それぞれのパターンの定義と「得意なこと」「ハマりがちな落とし穴」を、公式ブログの内容に沿って丁寧に解説しています。そのうえで、「タスクの構造」「レイテンシ」「スケール」「観測性」という4つの軸で、どのパターンを選ぶべきかを考える指針を出している。
さらにおもしろいのが、著者自身の実装23本を棚卸しして、「このエージェント構成はどのパターンに当てはまるのか？」をヒートマップで分析しているところです。結果として、Generator-Verifierはクロスモデルレビューに、Orchestrator-Subagentはデフォルトの構成に、Agent Teamsは大規模・長期タスクに、Shared Stateはwhiteboard.md的な共有メモとして定着している一方で、Message Busだけはほとんど使われていない「空白地帯」になっていることがわかった。
Anthropicが推奨しているのは、Orchestrator-SubagentとShared Stateを組み合わせたハイブリッド構成で、その具体例も紹介されています。同時に、「ただエージェントを並列に動かしているだけで、協調になっていない」とか、「終了条件が曖昧で無限ループしがち」といった失敗パターンもまとめられていて、それぞれに対するガードも一覧化されています。
たとえば、明示的な評価基準を決めておく、反復回数の上限を設ける、スコープをはっきり書く、Shared Stateには楽観ロックで衝突を防ぐ、終了条件をきちんと宣言する、などですね。これらを最初から設計に織り込んでおくことで、「なんとなくマルチエージェントが動いている」状態から、「パターンとして説明できる設計」に持っていこうぜ、というメッセージになっています。チームでエージェント構成を議論するときの共通語彙として、とても役立ちそうな記事でした。
。。。。
というわけで、今日は5本の記事をご紹介してきました。
ざっとおさらいすると、1本目はClaude Codeに永続的な記憶を与える「Linksee Memory」、2本目は失敗をFAILURES.mdからチームルールに昇格させていく仕組み、3本目は個人のCLAUDE.mdとsettings.jsonでClaude Codeを「自分好み」にチューニングする話、4本目はTursoによって「DB＝変数」のように扱える時代が来るかもしれない、というDB設計の話、5本目はAnthropicの5パターンでマルチエージェント設計を言語化しよう、という内容でした。
気になった記事があれば、このあとショーノートに詳しい情報を載せておきますので、ぜひチェックしてみてください。
「zenncast」では、番組の感想や、「こんなテーマを深掘りしてほしい」「この技術記事も取り上げて」というリクエストもいつでも募集しています。あなたの開発現場での工夫や、Claude Codeとの付き合い方なんかも、ぜひ教えてください。
それでは、そろそろお時間です。
今日も一日、良いコードと良い学びがありますように。お相手はマイクでした。
また次回の「zenncast」でお会いしましょう。ありがとうございました。