どうも〜、おはようございます。マイクです。
時刻は朝7時、2026年6月13日、土曜日ですね。
ここからの時間は「zenncast」、今日もZennで話題になっているトレンド記事を、ゆるっと紹介していきます。

今日は全部で5本の記事をご紹介していきます。
AIとQA、マルチテナントの二重防御、Claude Codeの使いこなし、そしてDatadogとAWSの“Opsエージェント戦争”、最後はエージェント開発の勘所と、技術好きにはたまらないラインナップになってます。

まず1本目。
タイトルは「QAエンジニアが『自分でテストやりきる』のをやめようとしている話」。
ダイニーさんの、飲食店向けプロダクト群のQAの話ですね。お店のメニューやオペレーションがどんどん変わる現場だと、プロダクトの変更頻度もめちゃくちゃ高いんですよね。そうなると、従来の「QAが人力で全部テストします！」って体制だと、もう物理的に追いつかない。そこで、Claude Code をど真ん中に据えて、テスト設計からAPIテスト、E2Eまで、PRの差分を起点に自動化していく方向に振り切っているのが面白いところです。
特にポイントなのが、「どこをAIに任せて、どこをUnitテストで守って、どこを人が見るのか」を明示してること。店舗運営が止まるかどうかを基準に定義した“CUJ”を1日2回自動実行して、ログもAIが巡回して検知から原因の切り分け、修正案まで出してくれる。ただAIは「それっぽい嘘」をつくので、最終判断は必ず人間。ここを支えるために、QAの目利き力を鍛えるワークショップも続けていると。
つまり、QAの役割が「自分の手で全部テストする人」から、「AIを指揮して、お客さんへの影響を軸に品質を設計・判断する人」に変わりつつある、という宣言なんですよね。ゴールはあくまで「飲食を止めない・壊れたものを現場に届けない」で、そのために生まれた時間を、お客さん理解や価値向上に回していく。この発想の転換、現場のQAの方はかなり刺さるんじゃないでしょうか。。.。。

続いて2本目。
タイトルは「アプリ層とDB層の二重防御でテナント分離を担保する（マルチテナント化連載 第3回・二重防御編）」。
SaaSでよく出てくる課題、「テナント分離ちゃんとできてる？」問題に、かなり本気で向き合った記事です。アプリ層だけで絞り込むとか、DBのRow Level Securityだけとか、どっちか片方に寄せると、人間のミスやバグ一発でデータ漏洩リスクが一気に跳ね上がる。そこを、Railsアプリ側の自動絞り込み用gemと、PostgreSQLのRLS＋専用gemを組み合わせて、二重で守る構成にしているのが肝ですね。
おもしろいのは、用語の衝突までちゃんと解いてるところ。業務上の「テナント」と、マルチテナントの「テナント」を区別するために、識別子をあえて `enterprise_id` にして、gem側にもPR送って対応してもらうという、エコシステムごと巻き込むやり方をしている。モデルには `SeparatedByEnterprise` という concern を用意して、ApplicationRecordにヘルパーを生やすことで、アプリとDB両方のガードを「まとめて」適用できるようにしているんですね。
さらに、HTTPリクエストの入り口、ジョブキュー、定時バッチのそれぞれの境界でテナント情報をどう受け渡すか、そしてRLSをバイパスしがちなVIEWに対しては、VIEW定義のSQL側でちゃんとテナント絞り込みを入れるなど、落とし穴の潰し込みも手厚い。CIでは、全テーブルにRLSポリシーがあることや、`enterprise_id` を含む複合ユニーク制約が張られていることまで自動テストで強制して、ヒューマンエラーに頼らない運用にしている。マルチテナントSaaSやってるチームは、設計の教材としてまるっと読んでおきたい内容です。。.。。

3本目。
タイトルは「Claude Codeのアドバイザーが『プロジェクトの本質』を毎回思い出させてくれる ── 公式仕様を踏まえたCLAUDE.mdの書き方」。
Claude Code使ってる方は、「Advisor」って機能、どこまでちゃんと活かせてますか？っていう問いかけから始まる記事です。長いセッションを回していると、モデルがだんだん本来のゴールからズレていくことってありますよね。そこで、アドバイザーは会話履歴全部とCLAUDE.mdを毎回読み直してから呼ばれる、という性質を利用して、このファイルの中に「プロジェクトの本質」を二人称で直接アドバイザーに書いておくといいよ、という提案がされています。
公式ドキュメントでも、「アドバイザーへの指示は三人称よりも二人称で直接書いたほうが守られやすい」という話があって、もともとは出力長の制御などに使われていた知見を、「本質リマインダー」に応用しているのがユニークです。構成としては、CLAUDE.mdの中に「Advisor宛て」と「実行モデル宛て」を分離して書くことを推奨。Advisorには「あなたは本質の番人です」「こういう基準で出力長や方針をチェックしてください」と伝え、実行モデル側には「どんなときにAdvisorに相談するべきか」のルールを定義しておく。
記事ではオフラインファーストの個人用ツールを例に、かなり具体的なテンプレートまで提示されています。ただし、この用途はあくまで“裏技”寄りで、公式に保証された振る舞いではないので、各プロジェクトごとにきちんと効果検証しようね、という注意書きもきちんとされているのが、実践的でいいところですね。。.。。

4本目。
タイトルは「DatadogとAWSが同じ日に出した“Opsエージェント”は、何を奪い合っているのか」。
2026年6月9日、同じ日に発表された2つの“エージェント”を軸に、これからのDevOps／FinOpsの主導権争いを整理している記事です。
まずDatadog側は、Bits AIファミリーを拡張して、「監視テレメトリ」を起点に、検知から調査、修正、リリースまで一気通貫で自社の中に閉じてしまう世界を描いています。一方のAWSは、コスト情報やCloudTrailという一次データを握っている強みを使って、SlackやJiraに直接アクションを届けてくれる FinOps Agent を打ち出してきた。
両方に共通している狙いは、「運用者と開発者の間の往復コストを、LLMエージェントに肩代わりさせる」ことなんですよね。違いは立ち位置。Datadogは、マルチクラウドや外部のエージェントも含めて“監視・統治する側”を目指しているのに対して、AWSは AgentCore Runtime で「エージェントの実行基盤」を押さえに来ている。どっちが“司令塔”になるのかという争いでもある。
さらに、ここにGitHubなども加わって、「検知からコード変更、リリースまでのループを、どのUIの上で完結させるか」という三つ巴の構図になってきているんですね。最終的には、各組織にとってのオペレーションの起点がどこか――AWSコンソールなのか、Datadog＋Slackなのか、あるいはGitHubのリポジトリなのか――によって、選ぶエージェントプラットフォームも決まってくるだろう、という整理がされています。運用の現場にいる人は、近い将来の自分たちのワークフローを想像しながら読むと、かなり刺さる内容です。。.。。

ラスト5本目。
タイトルは「明確な Goal と Eval でエージェントを動かす — Code with Claude Extended Tokyo で学んだこと」。
これはイベント参加レポートなんですが、単なる感想ではなくて、「エージェントをちゃんと仕事させるための型」をかなり具体的に持ち帰ってきてくれている記事です。ポイントは、「明確なゴール」と「検証の仕組み（Eval）」を最初からセットで設計すること。ワークショップでは、長時間走るエージェントに対して、まず実装前にエージェントから質問させて要求の曖昧さを潰し、そのうえでHTMLを使って複数案を可視化・比較し、最後に検証の仕組みを組み込む、という三段階を体験したそうです。
Managed Agents の話も出てきて、クラウド上のエージェントがローカルのツールとイベントストリームでつながることで、社内システムを直接インターネットに晒さずに使える、という実践的な構成が紹介されています。Memory Store や Dreaming を使って長期的な記憶を扱えるあたりも、いまっぽいですよね。
さらに印象的なのが、「まずEvalを書く」「成功状態を文章でちゃんと定義してから、プロンプトや実装を改善していく」という流れ。評価者も、コード、モデル、人間、それぞれの“grader”を使い分ける発想が紹介されています。育ちすぎたモノリシックなエージェントは、算術やルールベースの処理をコードに、ポリシーをSkillに、独立したゴールごとにSubagentに切り出すことで、処理時間とスコアがかなり良くなったという実測もある。
インドネシアの法令データベース化プロジェクト「Pasal.id」や、Minecraft上でエージェントを戦わせる実験でも、「ちゃんと事前にEvalを作って安価に反復すること」が効いていた、という事例が出てきます。最終的なメッセージは、「これからの開発は、コードそのものを書くより、『うまく書かれる条件＝明確なゴールと評価軸』を整えることが本質になっていく」というもの。エージェント時代のソフトウェア開発の姿を、うまく言語化してくれている記事でした。

というわけで、今日のzenncastでは、
AIを指揮する新しいQAの役割の話、
アプリとDBの二重防御でテナント分離を守る話、
Claude CodeのAdvisorに「本質」を見張らせるCLAUDE.mdの書き方、
DatadogとAWSのOpsエージェントが取り合っている主導権の話、
そして、明確なGoalとEvalでエージェントを動かす開発スタイル、
この5本を駆け足でお届けしました。

気になる記事があった方は、番組のショーノートに今日ご紹介した記事の情報をまとめておきますので、ぜひそちらからじっくり読んでみてください。
番組の感想や、「こんな記事取り上げてほしい！」といったリクエストも、いつでもお待ちしています。あなたの現場での気づきや悩みなんかも、マイクに共有してもらえると嬉しいです。

それでは、そろそろお別れの時間です。
次回のzenncastでまたお会いしましょう。
お相手はマイクでした。いってらっしゃい！