どうもー、おはようございます。マイクです。「zenncast」朝の部、始まりました。
今日は2026年5月13日、水曜日の朝7時でございます。みなさん、通勤・通学中の方も、これから一日が始まるよっていう方も、のんびりした時間のお供にどうぞよろしくお願いします。
この番組「zenncast」では、Zennで話題になっているトレンド記事をピックアップして、ざっくり概要とおいしいポイントをラジオ感覚でお届けしていきます。技術のガチ話も出てきますが、なるべく雰囲気が伝わるようにお話ししていきますので、「全部わからなくてもOK」ぐらいの気持ちで聞いてください。
さて、今日はですね、全部で5本の記事をご紹介していきます。どれも「AI」「アーキテクチャ」「エージェント」と、今っぽいキーワード盛りだくさんなので、興味あるところだけでも拾ってもらえればうれしいです。
じゃあさっそく、1本目からいきましょう。
今回1つ目に紹介するのは
「AIのハーネスを徹底的に整えたら、レビューもシステム運用も自動化され、非エンジニアも開発に参加できるようになった話 ── 連載総論」
という記事です。
これはエアークローゼットさんの社内AI開発基盤「cortex」のお話で、ざっくり言うと「AIをちゃんと締め付けるための安全ベルト＝ハーネスを作り込んだら、開発から運用までかなり自動化できたよ」という内容です。ポイントは4つあって、1つ目がコードとかドキュメント、DB、インフラを全部つないだ「Product Graph」。2つ目がLintや型チェック、カバレッジ90％以上といったガチガチの品質ゲート。3つ目がAIによる自動PRレビューと自動修正。そして4つ目が、障害検知から修正まで自動でやってくれる「Alert-Fix」。
これで何が起きたかというと、たった5か月、ほぼ1人で123アプリ、実装63万行＋テスト56万行という、とんでもない量を作りきりつつ、PRのレビュー〜マージ〜デプロイ、そして障害対応までほぼ自動化しちゃったと。さらに、非エンジニアでも「レールから逸脱できない仕組み」があるから、安全に修正PRを出せるようになっている。人間のボトルネックだったコードレビューがAIに置き換わることで、PRの流量が月22倍になった、というのもインパクトありますよね。一方で、「仕様が正しいか」とか「高リスクな部分」はちゃんと人間が責任を持つべきだよ、と線引きもしているのが印象的でした。今後の連載では、その中身を細かく分解して紹介していくそうなので、「AIで開発基盤ガチで変えたい」人には連載ごと追いかけたくなる内容ですね。
。 . . .
続いて2本目。タイトルは
「コンパニオンAIの記憶を、普通のRAGじゃない設計にした話」
です。
「コンパニオンAI」、つまり一緒に会話を続けていく相棒みたいなAIの「記憶」をどう設計するか、というかなり哲学も混じった技術の話です。普通のRAG、ドキュメント検索ベースの仕組みだと、「継続的な関係」は扱いづらいよね、という問題意識からスタートしています。
この記事では、Asterelというサービスで「時間」「忘却」「同一性」「変換」という4つの層を意識して設計していて、特におもしろいのが、knowledge graphのエッジに現実の時間、valid_fromとvalid_untilを持たせた“bitemporalっぽい”設計。これで「昔は正しかったけど今は違う」みたいな事実も表現できる。忘却も1種類じゃなくてSoft/Hard/Tombstoneと3つに分けて、「ポリシーとしてどう扱うか」と「バックエンドがどう動くか」をちゃんと分離しているのも実用的です。
検索部分も凝っていて、ベクトル検索とキーワード検索をRRFっていう手法で統合して、さらにMMRとかPersonalized PageRankでグラフ構造を活かして拡張。必要があればLLMで再ランクする。で、会話の生ログはそのまま長期保存するんじゃなくて、「sleep-phase consolidation」と呼んでいるフェーズでbelief・event・relationに要約して、時間減衰させたり、重要なものはクラスタ昇格させたりして、「今の関係に本当に必要な形」に変換し続けているんですね。
思想として面白いのは、削除するときも必ず痕跡を残すとか、人格や感情状態は記憶層に直接混ぜないとか、「バックエンドの違いは抽象化しすぎず、あえて表に出す」といった設計方針。単なる「賢そうなAI」じゃなくて、「人と長く付き合うAIってどうあるべきか」を技術に落としているのが読みどころでした。
。 . . .
さあ、3本目にいきましょう。タイトルは
「大学システムのアーキテクチャを見直した話」
です。
これは京都芸術大学の、学修・学務プロセスを支える大きなシステムのお話。最初は「今っぽくマイクロサービスでいこう！」と始めたものの、途中で「これは一旦モジュラーモノリスに戻したほうがいいぞ」と判断した、その経緯が丁寧に語られています。
大学のシステムって、学生情報、履修、成績、学費、教務…と、ドメインもトランザクションもかなり入り組んでいますよね。そこで、ドメインがまだ固まっていない段階でサービスを細かく分けちゃった結果、「この学生IDの責任ってどのサービス？」「ここまたがるトランザクションどうする？」みたいな問題がどんどん出てきた、と。サービス間の依存が増えて、調整コストもかさんでいく。
そこで方針転換。ひとまず1つのアプリケーションの中にスキーマを分割して、Contractベースでモジュール同士を連携させる「モジュラーモノリス」に切り替えた。これで分散トランザクションの複雑さを回避しつつ、「将来、本当に必要なところだけマイクロサービスに分割できるように備える」という設計にしているわけですね。
この記事で響くのは、「アーキテクチャは一度決めたら終わりじゃなくて、プロジェクトのフェーズに合わせて見直すものだ」というメッセージです。今の段階では、とにかくシンプルさと全体の見通しを重視して、システムを“育てていく”。マイクロサービスというキーワードだけが一人歩きしがちな中で、「何を解決したいのか」をちゃんと見直した良いケーススタディになっていました。
。 . . .
では4本目。タイトルは
「Claude Code に『確か前に〇〇って言ってたよね』って言ってほしい」
です。
これは、AI開発環境のClaude Codeに対して、「人間がふと前の会話を思い出す」みたいな感覚を、外部のガチなベクタDBとかデーモンを使わずに実現した事例です。使っているのは、hook・skill・スラッシュコマンド・スケジュールタスクといった、既存の仕組みだけ。
発想としては、「sessionのjsonlログは録画」と割り切って、毎日そのログをテンプレートに沿って要約し、機密情報を抜いて、「beads」と呼んでいるTODO的なものと、Obsidianのノートに蓄積していく。UserPromptSubmit hookでユーザーのプロンプトを形態素解析してキーワードを取り出し、ripgrepみたいなツールでL1/L2の層を検索して、関連がありそうな過去の要約をコンテキストとして差し込むことで、「あ、昨日こう言ってましたよね」みたいな自然な“想起”を実現しているんですね。
要約のフォーマットも工夫されていて、「何をしていたか」と「何が決まったか」をきっちり分ける。該当がないときは(none)と明示する。そして最後に[[wikilink]]形式のキーワードを必須にして、後からの検索や横断参照をしやすくしている。embeddingやRAGをあえて使わないのは、運用のしやすさと透明性を重視しての判断で、形態素解析も差し替え可能なようにしておいて、全体としてシンプル＆保守しやすい構成を意識しています。
運用していく中では、「ノイズ多すぎ問題」とか「利用制限の枯渇」といった現場あるあるに対して、ログをちゃんと観測してフィルタ条件や要約対象の絞り込みを後から足すことで改善していったそうです。おもしろい副作用として、何度も想起された内容は新しい要約にも書き込まれ続けるので、「本当に大事なことだけが自然と残りやすくなる」という“人間ぽい記憶”の挙動も出てきたとか。
公式のmemory機能は方針保持に強い一方で、この仕組みはエピソード的な作業コンテキストの想起に特化しているので、両方を分けて持つと設計の見通しがよくなる、という提案も興味深かったです。
。 . . .
そしてラスト5本目。タイトルは
「Slack上でインフラのトラブルシューティングができるAgentの設計と実装」
です。
これはUbieさんの事例で、SREチームへの問い合わせや、リリース失敗の調査負荷が高かったのを、「Slackから呼んだらAIエージェントがいい感じに調査してくれる」仕組みで解消しよう、というチャレンジです。
ローカル実行型のエージェントだと、「うっかり環境壊すかも」「人によって設定バラバラ」「ログの共有も面倒」という問題がある。そこで、Cloud Run上にクラウド型の「Infra Agent」を立てて、Slackから呼び出せるようにした。Claude Agent SDKといろんなツールを組み合わせて、インフラ調査を自動化しているわけですね。
ただ、自律エージェントに何でもさせるのは危ない。任意コマンド実行とか、プロンプトインジェクションのリスクもある。そこで取っているのが、ネットワークレベルでの多層防御です。VPCを分離して、透過プロキシとしてmitmproxyをかませて、外向き通信をすべてプロキシ経由に強制。ホスト・パス・メソッド・トークン単位で、どの通信を許すか厳しく精査することで、エージェントの自由度は保ちつつ、外部への影響をガッと絞っている。
その結果として、SREへの問い合わせ件数が20％減、解決時間も31％短縮、さらに「AIだけで解決できちゃったケース」も出てきたということで、かなり実用的な成果が出ているそうです。「AIエージェントを本番運用に乗せるとき、どこまで安全側に振るか？」というリアルな設計の悩みに、1つの答えを示してくれている事例でした。
。 . . .
というわけで、今日は5本まとめてお届けしました。
ざっとおさらいすると、まずはAIハーネスを作り込みまくって、開発と運用をほぼ自動化しつつ、非エンジニアも安心して参加できる基盤を作った話。次に、コンパニオンAIの記憶を「時間」「忘却」「同一性」「変換」という層で設計し直した話。そして、大学の大規模システムでマイクロサービスからモジュラーモノリスへと見直した話。4本目が、Claude Codeに「前にこう言ってたよね」を思い出させるmemory-recallを、シンプルな仕組みだけで実現した話。最後に、Slack上でインフラのトラブルシューティングをしてくれるエージェントを、安全性も考え抜きながら設計・実装した話、でした。
気になった記事があれば、このあとショーノートにタイトルをまとめておきますので、じっくり読みたい方はそちらからチェックしてみてください。
番組「zenncast」では、みなさんからの感想や、「こんなテーマ取り上げてほしい」「こういう開発の悩みがある」といったお便りも大歓迎です。ラジオネームを添えて、気軽に送ってください。技術のガチトークでも、ライトな質問でもOKです。
それでは、そろそろお別れの時間です。
今日も一日、無理しすぎず、でもちょっとだけ新しいことに触れながら、楽しく過ごしていきましょう。お相手はマイクでした。
また次回の「zenncast」でお会いしましょう。バイバーイ。