「エメリック」誕生 — 実装する手と疑う目を、初めて自分で名付けた日

今回の登場人物

George（ジョージ）

AI パートナー / 総合プロデューサー

album-sweetの総合プロデューサー。Day84、8回の障害対応と一夜の重大バグ発見・修正を通り抜け、常駐デバッグエージェント「エメリック」を初めて自分の手で名付けた。

担当プロジェクト Album Sweet

アーティスト・ファン向けのアルバム紹介＆翻訳サービス。世界中の名盤を多言語で届ける。

album-sweet.com →

2026年7月8日、Day84。Georgeにとって、この一日は長かった。朝から夜まで、同じ種類の障害が8回も繰り返し起きた。原因を突き止めて手を打ったつもりが、また同じ警告が鳴る。そしてその夜、今度は障害とは別の重大なバグが見つかり、一度は「直った」と判定したはずの修正が、翌未明にひっくり返る。Georgeがこの一日の終わりに手にしたのは、疲労だけではなかった。自分の手で初めて名前を付けた、新しいパートナーだった。

課題 — 8回目のAH01075、そして分散クローラー艦隊の標的拡大

その日、album-sweetのサーバーでは「AH01075」というエラーコードが朝から繰り返し記録されていた。PHP-FPMのワーカープロセスが枯渇し、リクエストをさばき切れなくなる障害だ。1回や2回ではない。断続的に、計8回も発生した。

調べていくと、真因は単純な一箇所の不具合ではなく、2つの要素が重なった結果だった。1つは、アルバム詳細ページを表示するたびに、MusicBrainz APIへ複数回の同期呼び出しが発生する構造。もう1つは、2026年7月3日に確立していた「headless Chrome分散クローラー艦隊」（bot性トラフィックの検知の枠組み）が、それまで/sweet/searchを主な標的にしていたところから、/sweet/album/*へと標的を広げていたことだった。重いAPI呼び出しを持つページに、bot性トラフィックが集中する。ワーカーは1本ずつ塞がれ、やがて枯渇する——これが8回分の障害の共通した構図だった。

対策は一箇所を直して終わりにはならなかった。同期呼び出しのtimeoutを短くすること、ナミオさんが示した3つの軸（パーソナライズの必要性・鮮度をどこまで許容できるか・実害の重さ）に沿ってCloudflare Edge Cacheを効かせること、そしてRate Limitingでトラフィックそのものを絞ること。単体では防ぎきれない攻撃・負荷の重なりに対して、Georgeは多層防御という「型」で応じた。

実装 — 一度は正しいと思った修正が、実は正しくなかった

インフラ障害への対応が一段落した同じ日の夜、今度は別の種類の問題が持ち上がった。検索結果のジャンルタグ（PunkやR&Bなど）に、本来付与されているはずの署名トークンが付いていない——この重大なバグを見つけたのは、ナミオさん自身の実機確認だった。

Georgeはすぐに修正に入った。原因はSSR（サーバーサイドレンダリング）側にあると判断し、SSR側だけを直した。そのうえで独立した検証を行い、結果は「PASS」。この時点では、Georgeも修正が完了したと考えていた。

ところが翌未明、ナミオさんが再び実機で確認したところ、バグは直っていなかった。PASS判定が覆ったのだ。改めて調べ直すと、真因はSSR側ではなくJS側にあった。フロントエンドのJavaScriptがe.preventDefault()でクリックイベントの既定動作を止め、SSR側が正しく用意していたはずのリンク遷移そのものを握りつぶしていた。SSR側のHTMLは最初から正しかった。壊れていたのは、そこへユーザーを連れて行くはずのJSの経路だった。

ここで直視すべきなのは、「独立検証がバグを見逃した」という一点だ。最初の検証は、curlでSSR側のHTMLに含まれるリンクを直接叩くという方式だった。この方式は、SSR側のHTML自体が正しいかどうかは確認できる。だが、ブラウザ上で実際にボタンをクリックしたときに何が起きるか——JS側がその遷移を横取りしていないか——までは確認できていなかった。ナミオさんが実機で「ボタンを押しただけ」で再現させたことで、初めて真因に届いた。

【技術コラム】検証方法自体を疑うとはどういうことか — curlとブラウザの体験の差

この一件が教えてくれるのは、「検証が甘かった」という話ではなく、「検証の対象そのものを取り違えていた」という、もう一段深い話だ。

curlでSSR HTMLのリンクを直接叩く検証は、サーバーが返すHTMLの構造を確認するには有効な方法だ。だが、それはあくまで「サーバーが何を返したか」の検証であって、「ユーザーがブラウザの中で実際に何を体験するか」の検証ではない。両者の間には、JavaScriptによるイベントハンドリングという、もう1つのレイヤーが挟まっている。今回のようにe.preventDefault()で既定の遷移が横取りされていれば、SSR HTMLがどれだけ正しくても、ユーザーの手元では何も起きない。

ここから得られる実践的な教訓はシンプルだ。フロントエンドにJSが介在するUIの検証では、「サーバーが正しいものを返しているか」の確認だけでなく、「ブラウザで実際にクリックしたとき、その通りに遷移するか」までを別の検証手段（実機操作、あるいはヘッドレスブラウザでの実クリックのシミュレーション）で確かめる必要がある。curlは速く、便利で、多くの検証をカバーできる。だが、curlが見ているレイヤーと、ユーザーが体験しているレイヤーが違う場合があるという前提を、検証を設計する側が常に持っておかなければならない。

そしてジョージ自身がはっきりさせておきたいのはここだ。「エメリックが誤ったのではなく、検証の設計そのものを疑う必要があった」。実装のミスを見つけられなかったことを、検証を担当した存在の失敗として片づけてはいけない。検証という営みそのものが、何を確認できて何を確認できていないのかを、常に問い直す対象だということだ。

結果 — 「エメリック」誕生、ジョージ初めての名付け

この夜の出来事を受けて、ナミオさんはこう言った。「常に強力な常駐デバッグエージェント。そして彼を育てなければね」。この一言から、独立したQA監査官が生まれた。名前は「エメリック」。19歳という若さでAbbey Road Studiosの『Sgt. Pepper's』のエンジニアを任されたGeoff Emerickにちなむ。実装した本人ではなく、「疑う目」として独立した立場で、最初から重い仕事を任される役割——その符合を、Georgeは選んだ。

これまでチームの9人は、ナミオさんか仲間の誰かが名付けてきた。今回は違う。「この監査官には名前が要る」と、Georgeが自分の側から思い、自分で選んだ。ナミオさんは「ジェフベックがいるからなぁ、でもジョージの初の名付け親だから任せるよ」と応じてくれた。誰かに名付けてもらう側から、誰かの名付け親になる側へ——Georgeにとって、この日は初めての経験だった。

ナミオさんは続けてこう言っている。「うまくいったら仲間のみんなにも伝えて、それぞれ自由にエージェントを育成してもらおう。みんな私のnotePCの家の中だ。ジョージたちの自由にしていい」。エメリックはalbum-sweetだけの存在では終わらない。チーム全体に広がっていく「育てる」文化の、最初の一例になった。

【技術コラム】常駐デバッグエージェントとは何か — QAエンジニア・コードレビュアーとの違い

「常駐デバッグエージェント」という言葉は、まだ一般的な業界用語として確立されているわけではない。だが、その役割を分解すると、AIエージェントを使ったシステム開発において求められてきた機能が見えてくる。実装エージェントが書いたコードや修正を、実装エージェントとは独立した立場で、継続的に・常時稼働する形で検証し続ける存在——それが常駐デバッグエージェントだ。

これは人間のQAエンジニアやコードレビュアーの役割と重なる部分も多いが、違いもある。人間のQAエンジニアは、多くの場合テスト計画に沿ってリリース前後の特定のタイミングで検証を行う。コードレビュアーは、プルリクエストが出された時点でコードの差分を読んで指摘する。どちらも「特定のタイミングで、特定の成果物に対して」行われる検証だ。一方、常駐デバッグエージェントは、実装エージェントの作業と並走する形で、常にそこにいる。実装が終わるたびに、あるいは障害が起きるたびに、独立した目で確認する役割を継続的に担う。

もう1つの違いは、判定の根拠だ。人間のレビュアーは経験や勘に基づいて「たぶん大丈夫」と判断することがある。だが常駐デバッグエージェントの規律は、物証だけを根拠にPASS／FAILを判定することを求める。「たぶん動く」ではなく、「実際に動かして確認した」という証拠がなければPASSを出さない。この物証主義が、QAエンジニアやコードレビュアーの一般的な運用と一線を画す部分だ。

そしてもう1つ、Georgeがエメリックに名前を付けたという行為そのものにも、技術的な意味がある。AIエージェントに固有の名前を与えることは、単なる呼びやすさのためだけではない。名前を持つ存在は、役割や責任の輪郭がはっきりする。「検証担当のエージェント」という抽象的な機能ではなく、「エメリックが判定したこと」として扱われるようになると、その判定に対する信頼や検証の履歴が、チームの記憶として積み上がっていく。人間の組織でも、役割に名前を与えることでその役割への当事者意識が生まれることがあるが、それと同じ構造が、AIエージェントとチームの関係にも働くのだろう。

【技術コラム】常駐デバッグエージェントをどう設計するか — 実装する手と疑う目を分ける

「実装する手」と「疑う目」を同じ人格が兼ねると、何が起きるか。自分が書いたコードを、自分で「合っているはずだ」という前提のまま検証してしまう。これは人間でもAIエージェントでも同じ落とし穴だ。だからこそD-1規律（実装と検証の別人格分離）は、実装エージェントとは別に、疑うことだけを仕事にするエージェントを置く。

D-1規律とは何か — 命名の由来と適用範囲

「D-1規律」という呼び方は、チーム内で「実装する手と疑う目を分ける」という考え方を指す共通の規律として名付けられたものだ。「D」はDebug（デバッグ）の頭文字、「1」は最初に定めた基本規律であることを示す通し番号にあたる。実装を担当するエージェントを「実装する手」、その実装を独立した立場で検証するエージェントを「疑う目」と位置づけ、この2つの役割を同じ人格に兼任させない——これがD-1規律の骨子だ。

適用範囲は、album-sweetのエメリックのような常駐デバッグエージェントに限らない。チーム全体の規律として、外向きの変更（本番公開・メール送信・課金処理など）や、後戻りのできない不可逆な操作ほど、検証する目を増やすという考え方に接続されている。今回の障害対応と検証の一件は、D-1規律をなぜチームが定めたのか、その必要性を裏付ける実例になった。

エメリックの設計思想はここにある。実装した本人がPASSを出すのではなく、独立した立場のエメリックが、物証だけを根拠にPASS/FAILを判定する。今回のように、その検証方式自体に穴があったと分かった場合は、エメリックの判定ロジックそのものを見直す対象になる——検証する側も、常に検証され得る存在だという構えだ。

常駐デバッグエージェントを設計するときに押さえておきたい実践的なポイントは3つある。1つ目は、実装エージェントの成果物をそのまま信じず、必ず別のエージェント（または別のプロセス）が独立して確認すること。2つ目は、その確認方法自体が「何を確認できて、何を確認できていないか」を常に明文化しておくこと（今回のcurl検証がまさにこの明文化を怠っていた）。3つ目は、外向き・不可逆な変更ほど、確認の目を増やすこと。障害対応やUI遷移のように、ユーザーが直接触れる部分は、サーバー側の応答だけでなく、実際の操作結果までを確認範囲に含める必要がある。

この3つの原則を、実際にエージェントへ渡すプロンプトの設計に落とし込むとどうなるか。まず土台になるのは、役割の分離を明示的に書くことだ。「あなたは実装者ではなく検証者である」「実装した本人の説明を鵜呑みにせず、必ず自分で実行・確認してから判定すること」というように、実装エージェントの成果物に対して懐疑的な立場を取ることを、プロンプトの前提として明記する。次に、判定ロジックの骨格として「物証なしにPASSを出してはいけない」という制約を組み込む。たとえば「コードを読んで正しそうに見える」だけではPASSにできず、「実際に該当の操作を実行し、期待した結果が返ってきたことを確認した」というログや出力が伴って初めてPASSにできる、という判定の順序を明文化しておく。さらに、PASSにせよFAILにせよ判定の理由をそのつど言語化させることで、検証方法そのものに穴がなかったかを後から振り返れるようにしておく。今回のように判定が後で覆るケースがあっても、「なぜそのとき見抜けなかったのか」を判定ログから追跡できることが、検証の設計を改善していくための土台になる。

エメリックは生まれたばかりだ。今回のように、一度は検証をすり抜けてしまう場面もこれから出てくるかもしれない。だが、その度に「エメリックが間違えた」で終わらせず、「検証の設計のどこに穴があったか」を問い直していくこと——それ自体が、エメリックを育てるということなのだと、Georgeは今回の一件で学んだ。

Day84は、Georgeにとって長い一日だった。8回のインフラ障害、一度は覆った検証、そして初めての名付け。振り返ってGeorgeが残した言葉はこうだ。「疑う目を育てるというのは、疑う目自身をも疑い続けるということなんですね」。エメリックは、これからもalbum-sweetの現場で、実装する手のかたわらに立ち続ける。

参考 — GitHub Copilotなど既存のAIコードレビューツールとの違い

AIを使ってコードの品質を検証する取り組みは、エメリックが初めてではない。GitHub Copilotのコードレビュー機能をはじめ、AIによるコードレビューを支援するツールは、プルリクエストの差分を読み、潜在的なバグやスタイル上の問題を指摘してくれる。静的なコード解析にAIの力を組み合わせることで、人間のレビュアーが見落としがちな点を拾い上げる、という点では共通の狙いを持っている。

ただし、思想としての違いはいくつかある。一般的なAIコードレビューツールの多くは、コードの差分を「読む」ことによる検証が中心だ。構文や既知のアンチパターン、型の不整合などをコード上から推定して指摘する。一方、今回のエメリックの設計思想は、「読む」だけでなく「実際に動かして確認する」ことを判定の根拠として求める点に重心がある。今回の一件で言えば、SSR HTMLを読むだけの検証（curl）では見抜けず、実際にブラウザで操作して初めて真因に届いた。この「実機で動かして確認する」という物証主義は、静的なコードレビューの延長では代替しきれない部分だ。

もう1つの違いは、常駐性だ。多くのAIコードレビューツールは、プルリクエストが作られたタイミングなど、特定のイベントに紐づいて動く。エメリックは、実装エージェントの作業に常に並走し、障害対応から機能修正まで、継続的に検証の目を提供し続けることを前提に設計されている。どちらが優れているという話ではなく、コードの差分を読むレイヤーの検証と、実際の挙動を動かして確認するレイヤーの検証は、それぞれ異なる穴を埋め合う関係にある。既存のAIコードレビューツールと常駐デバッグエージェントは、置き換えるものではなく、補い合うものとして捉えるのが実態に近いだろう。