こんにちは、イノベーションセンターのNetwork Analytics for Security（NA4Sec）プロジェクトの山門です。 この記事では、2025年12月18日-19日に開催されたカンファレンスNCA Annual Conference 2025へ登壇してきた模様を紹介します。 組織におけるドメイン名の「終活（廃棄）」に伴うリスクをテーマに、利用終了ドメイン名に対する2.3億件のログ分析結果を説明しました。ECS（EDNS-Client-Subnet）を用いた分析により、「利用終了後も攻撃・スキャンが絶えない」という実態や、観測行為自体が攻撃を誘発する「観察者効果」といった興味深い知見を解説します。 NCA Annual Conferenceとは NA4Secプロジェクトとは 講演内容 ドメイン名の「終活」という課題 ECSの活用 観測・分析環境 分析結果 結論 おわりに NCA Annual Conferenceとは NCA Annual Conferenceは、一般社団法人 日本シーサート協議会が主催する年次カンファレンスです。 本イベントは、企業や組織内でセキュリティインシデントに対応するCSIRT（Computer Security Incident Response Team）のメンバーが一堂に会する、国内でも大規模なコミュニティイベントの1つです。最新のサイバー攻撃動向や技術情報の共有にとどまらず、組織の枠を超えたCSIRT間の連携や、各組織が抱える課題解決のヒントを得ることを目的として開催されています。 特に、現場の実務者による知見の共有やワークショップを通じた「共創」の精神が重視されており、日本のサイバーセキュリティ対応能力の底上げを図る重要な場として位置づけられています。 NA4Secプロジェクトとは 私の所属するNA4Secプロジェクトについて紹介させてください。 NA4Secプロジェクトは、「NTTはインターネットを安心・安全にする社会的責務がある」を理念として、インターネットにおける攻撃インフラの解明・撲滅を目指すプロジェクトです。 NTTドコモビジネスグループにおける脅威インテリジェンスチームとしての側面も持ち合わせており、有事において脅威インテリジェンスを提供し、意思決定を支援することもあります。 イノベーションセンターを中心として、NTTセキュリティ・ジャパンやエヌ・エフ・ラボラトリーズからもメンバーが参画し、日夜攻撃インフラ(攻撃者の管理するマルウェアや C&Cサーバ など)を追跡しています。 講演内容 NA4Secプロジェクトの神田と、私（山門）の2名で、「『君の名は』と聞く君の名は。」というタイトルで、安易なドメイン名放棄に潜むリスク、観測から得られた知見、そして新しい管理アプローチについて講演しました。 登壇資料はこちらにアップロードしておきましたので、よろしければご覧ください。 ドメイン名の「終活」という課題 企業がかつて利用していたドメイン名を悪意を持つ第三者が取得した場合、フィッシングサイトに悪用されたり、ブランドイメージを失墜させたり、Search Engine Optimization（SEO）を悪用したりできるため、攻撃者にとって価値があります。そのためドメイン名の放棄後に第三者によって悪用される「ドロップキャッチ」のリスクが存在します。実際に「ドコモ口座」など複数事例でも問題が顕在化しています。 その対策として、当社ではドメイン名の永年保有ポリシーを策定していますが、「いつまでも持ち続ける」以外の選択肢を探るべく、利用終了ドメイン名に対する「アクセス実態」の観測と分析しています。 ECSの活用 今回発表した中では、「EDNS-Client-Subnet（ECS）」の挙動を調査しました。ECSとはRFC 7871で定義されており、DNS問い合わせにクライアントのIPサブネット情報を付加し、権威DNSサーバがユーザの地理的・ネットワーク的な位置をより正確に把握できるようにする仕組みです。DNSリゾルバの裏に存在する、実際に名前解決しようとしたクライアントのサブネットを意味します。 観測・分析環境 ログ収集環境を下図に示します。 利用終了したドメイン名宛のDNSクエリログ、Webアクセスログ、受信メール・DMARCレポートの3点をAWS上で収集およびJSON化し保管しています。今回はその中のDNSクエリログとWebアクセスログの2点に注目しています。 今回は、NA4Secプロジェクトの利用終了ドメイン名関連の施策の中で、初めてDNSクエリログとWebアクセスログを突合させることでアクセスの正体と目的の分析を試みました。DNSクエリログのECSをキーにWebアクセスログの送信元IPアドレスと突合し、DNSクエリログとWebアクセスログのタイムスタンプの差に着目しました。タイムスタンプの差が小さいと、当該ECSがWebアクセスのためにDNS名前問い合わせをした可能性が高いためです。 分析結果 以下のグラフは、各日付のDNSクエリのカウントをその日調査対象になっていたドメイン名の数で平均した値の遷移です。 以下の事柄が、分析により判明しました。 ログ分析から、利用終了後も大量のクエリが継続している 約2.3億件のDNSクエリログのうちGoogle / Cisco / Akamai など大規模DNSの resolver-ip からのクエリが9割以上を占める DNSで名前問い合わせ直後（24時間以内）に Webへアクセスしてきたものを調査した結果112リクエスト中、90件以上が攻撃またはスキャンである WordPress や Apache の既知脆弱性を狙ったアクセスが多数確認されました。Shellshock（CVE-2014-6271）、WebLogic RCE（CVE-2017-10271）、MobileIron RCE（CVE-2020-15505）、D-Link NAS のバックドア脆弱性（CVE-2024-3272）など、古い脆弱性も依然として集中的に狙われている 今回の分析から明らかになった問題の1つは、観測行為そのものがアクセスを誘発してしまうというジレンマです。 DNSレコードを返すことでサブドメイン探索が行われ、HTTP応答を返すことで脆弱性スキャンが始まるなど、観測行為が攻撃者を誘引し、その行動を変えてしまっている実情が見えてきました。 いわば「観察者効果」です。 その一方で、DNSクエリログ・Webアクセスログ単体だけではアクセスの目的や意図、アクセス元の素性を推し量ることは難しく、適切なアクションに結び付けることは困難です。 より正確に状況を把握し、利用終了ドメイン名に残存するリスクへ効果的に対応するためには、不要な「ノイズ」を除去して、本来残っているアクセスを見分けることが重要となります。 結論 これらの調査から得られた知見として下記のようにまとめられます。 DNSクエリログの一部の送信元のアクセス意図は攻撃やスキャンであることが、今回初めてDNSクエリログとWebアクセスログの2つを突合することで判明した 利用終了ドメイン名であっても攻撃・スキャンは日常的に行われる（今回の調査の対象は24年8月以前に利用終了したドメイン名） 2つのログ突合により、名前問い合わせをしてきた送信元のアクセス意図の理解が高まる（今回の調査では大半がスキャンや攻撃） おわりに 月日が経ってもアクセス数は減らず、「減少＝ドメイン名を安全に手放せる」の単純な判断材料にはならないことがわかりました。 また、現用ドメイン名にも同様の脅威が常に存在するため、サイバーハイジーン（基本的なサイバーセキュリティ対策を平時より実施すること）の徹底が不可欠だと言えます。 講演後の反応として、「同じくドメイン名の終活に悩みを抱えているが、運用・廃止ポリシーはまだ策定していない。今回の講演は、月日が経ってもアクセス数が減らない点や、曖昧な運用が悪意ある第三者によるドロップキャッチの原因になる点など、改めて組織内での運用ポリシーを策定するためのきっかけになった」というご意見もいただきました。 本カンファレンスを通じて、最新の技術動向や脅威情報を習得できたことはもちろんですが、同じ課題を持つ他社CSIRTとの「共創」のネットワークを再確認できたことが最大の収穫でした。一度取得したドメイン名の管理という地味ながらも避けては通れない課題が、いかに多くの実務者の皆さまの共通の悩みとなっているかを痛感しました。 「いつ、どうやってドメインを手放すべきか」という問いに対する最適解はまだありません。しかし、今回ご紹介したログ分析の手法や観測結果が、皆さまの組織における運用ポリシー策定の一助となれば幸いです。 NA4Secプロジェクトでは、今後もこうした観測と分析を継続し、インターネットをより安心・安全なものにするための知見を発信してまいります。 記事を最後までお読みいただきありがとうございました。

ども！最近 Claude Code に設計レビューを頼んでみている龍ちゃんです。 Claude に「この設計レビューして」と投げると、一般論しか返ってこないんですよね。「スケーラビリティを考慮しましょう」とか「セキュリティに配慮してください」とか。いや、それはそうなんだけど、 見てほしい観点を伝えてないから AIも答えようがない。 「OWASP Top 10 を確認して」とか「このフレームワークの公式ドキュメントと照合して」とか、 具体的な観点を渡せば AI の出力が変わる 。でも毎回それをゼロから調べて伝え直すのは現実的じゃない。調べたとしても、次のセッションではその知識がリセットされてまた同じ Web 検索をする羽目になるんですよね。 これを解決したのが「調査 → 構造化 → 注入」のパイプラインでした。 /research で調べた結果を docs/references/ に構造化して保存し、Skill や Agent が必要なタイミングでそのデータを読み込む。一度調査して整理すれば、あとは AI がフレームワークや評価基準を参照した上で分析してくれる。自分にはその正当性を完全には判断できないけど、少なくとも「根拠のある参考資料」として読めるレベルの出力が出てくるようになりました。 今回は、この仕組みの作り方と実際にどう変わったかを共有します。 今回の内容 なぜ AI の出力がイマイチになるのか 「調査 → 構造化 → 注入」パイプラインの全体像 実際の Before/After（SEO タイトル提案の例） ハマりどころと気をつけるポイント ※ちなみに Web 調査の自動化（ /research スキル）については 前回の記事 で詳しく解説してます。気になる方はそちらもどうぞ。 なぜ AI の出力がイマイチになるのか AI に自分の専門外の仕事を頼むとき、だいたい3つの問題にぶつかります。 1. AI が汎用知識しか持ってない 「PV データを分析して」と指示しても、AI が持ってるのは一般論だけ。マーケティングフレームワークに基づいた分析にはなりません。SEO のタイトル提案も同じで、具体的なチェックリストや基準がないからふわっとした答えしか出てこない。 僕も最初は「AI なら分析できるでしょ」と思ってたんですが、結果は「PV が多い記事に注力しましょう」みたいな誰でも思いつくようなこと。BCG マトリクス？ Pareto 分析？ エンジニアの僕にはそもそもそれが何か怪しいレベルで、AI の出力が正しいのかも判断できませんでした。 2. 毎回ゼロからやり直し 前のセッションでマーケティング分析手法について調べたのに、次のセッションではその知識がリセットされてる。また同じ Web 検索をして、同じような結果を読み込んで、コンテキストウィンドウを埋めていく。Claude Code のベストプラクティスにもこう書かれています。 “Most best practices are based on one constraint: Claude’s context window fills up fast, and performance degrades as it fills.” — Best Practices for Claude Code 毎回 Web 調査でコンテキストを埋めると、肝心の作業に使える領域が減っていく。調査と作業でコンテキストの取り合いをしてるようなものです。 3. 出力の良し悪しを検証できない これが一番厄介。自分が専門家じゃない領域だと、AI の出力が良いのか微妙なのかすら判断できません。でも references にマーケティングフレームワークの基準を入れておけば、少なくとも「KPI 指標に基づいた分析」「Pareto 原則に沿った投資判断」みたいに、根拠が明示された出力になる。正しさを100%保証できなくても、「なぜそう判断したか」が見えるだけで、参考資料として読む価値が全然違うんですよね。 この3つ、全部まとめて解決する仕組みを作りました。 今日から始められる最小行動 仕組みの全体像を見せる前に、まず試してほしいことがあります。2つのプロンプトを使うだけです。 1つ目のプロンプト（調査して保存） : SEO タイトル最適化のベストプラクティスについて調査して、title-optimization.md として保存して 2つ目のプロンプト（参照して実行） : title-optimization.md を参照して、この記事のタイトル案を3つ提案して これだけです。1つ目で調査結果を保存して、2つ目でそれを参照して作業する。思いつく例があれば、記事を読み進める前にやってみてください。 僕も最初はこの2つのプロンプトを繰り返してました。「Docker のセキュリティベストプラクティス調べて保存」→「それ見てレビューして」みたいな感じで。でもこれを何回かやると、保存したファイルがあちこちに散らばって「あのファイルどこだっけ？」ってなるんですよね。だから保存先を整理して、Skill から自動で読み込めるようにパイプラインとして仕組み化したんです。 次のセクションでは、その仕組み化したパイプラインの全体像を見せます。 解決策の全体像: 調査 → 構造化 → 注入 さっきの2プロンプトを繰り返すうちに、「これ毎回やるなら仕組み化した方がいいな」と思って作ったのがこのパイプラインです。 ステップ やること 保存先 役割 1. 調査 /research で Web 調査を自動化 docs/research/ 生データの収集 2. 構造化 調査結果を目的別に整理・蒸留 docs/references/ 再利用可能なナレッジに変換 3. 注入 Skill / Agent が必要な references を Read で動的ロード .claude/skills/*/references/ 等 AI が正確な出力をするための根拠 ポイントは、一度このパイプラインを通すと、あとは Skill を実行するだけで検証済みのナレッジが自動的に注入されること。毎回 Web 検索する必要がなくなります。 では、各ステップを順番に解説していきますね。 ステップ1: /research で調査を自動化する まずは調査の自動化から。 前回の記事 で詳しく紹介した /research スキルを使います。ざっくり言うと、Web 調査を Claude Code に自動でやらせる仕組みです。 やったことはこんな感じです。 Claude Code の Skill として /research コマンドを作成 調査用の Worker を複数並列で起動して、効率的に情報収集 調査結果は docs/research/YYYY-MM-DD-topic-slug.md に自動保存 例えば SEO タイトルの最適化について調べたいときは、こう実行するだけ。 /research SEO タイトル最適化 技術ブログ これで Worker が公式ドキュメント、技術ブログ、日本語の情報を並列で検索して、結果を docs/research/2026-02-05-seo-structured-data-tech-blog.md みたいなファイルに保存してくれます。バックグラウンドで動くので、調査中に他の作業を進められるのも地味にありがたい。 ただ、ここで注意点が1つ。 調査結果は「生データ」 です。網羅的に集めてくれるのはいいんだけど、そのままだと情報量が多すぎて使いにくい。この生データを「AI が使える形」に蒸留するのが、次のステップの話です。 ステップ2: 調査結果を構造化する（research → references の蒸留） 個人的には、ここが一番大事なステップだと思ってます。 /research で調査を自動化すると、網羅的に情報を集めてくれるのはありがたいんだけど、「人間が読もうと全く思わない」ボリュームになります。数千行のマークダウンファイルがドンと出てきて、そこから必要な知識をすぐ出せるかというと…無理でした。 そこで、調査の生データから「AI が使える形」に蒸留する工程を入れました。 research と references の違い docs/research/ docs/references/ 内容 調査の生データ（URL、引用、メモ） 目的別に整理されたナレッジ サイズ 大きい（調査の全記録） コンパクト（必要な情報だけ） 寿命 調査時点のスナップショット 継続的にメンテナンス 用途 あとから振り返る記録 AI が参照するリファレンス docs/research/ は「調べた記録」で、 docs/references/ は「使えるナレッジ」。research に直接 AI を繋ぐと数千行を丸呑みすることになるけど、references に蒸留しておけば必要な部分だけ読み込める。この違いは結構大きいです。 具体例: SEO の蒸留プロセス 実際に SEO タイトル最適化の調査結果を蒸留したときの例を見せます。 docs/research/2026-02-05-seo-structured-data-tech-blog.md（生データ、数千行） ↓ 蒸留 docs/references/seo/ ├── title-optimization-guidelines.md ← タイトル最適化基準 ├── power-words.md ← パワーワード一覧 ├── checklist.md ← チェックリスト ├── spark-framework.md ← SPARKフレームワーク └── meta-description-guidelines.md ← メタディスクリプション基準 1つの巨大な調査ファイルから、目的別に5つのファイルに分けています。こうしておくと、AI が「タイトルを考えるときは title-optimization-guidelines.md と power-words.md を読む」「メタディスクリプションを書くときは meta-description-guidelines.md を読む」と、必要なファイルだけを選んで読み込めるようになります。 蒸留のコツ 1ファイル1目的 : 「タイトル最適化」と「パワーワード」は分ける。混ぜると AI が不要な情報まで読み込む AI が参照しやすい形式 : 表、箇条書き、チェックリスト。文章でダラダラ書くより構造化されたデータの方が AI は正確に使える 出典を残す : 蒸留元の調査ファイルや参考 URL を記載しておく。あとから「この基準、本当に合ってる？」と検証できるように ステップ3: Skill / Agent に注入する（Progressive Disclosure） 最後のステップ。構造化した references を Skill や Agent に読み込ませます。 ここで使うのが、Claude Code Skills の Progressive Disclosure （段階的開示）という仕組みです。公式ブログにはこう書かれています。 “Progressive disclosure is the core design principle that makes Agent Skills flexible and scalable. Like a well-organized manual that starts with a table of contents, then specific chapters, and finally a detailed appendix, skills let Claude load information only as needed.” — Equipping agents for the real world with Agent Skills 要は、情報を3層に分けて必要なときだけロードする設計です。 レイヤー ロードタイミング サイズ Level 1: メタデータ 常にコンテキストに存在 ~100語 Level 2: SKILL.md Skill が発火したとき 500行以下推奨 Level 3: references/ 必要なときだけ Read で取得 事実上無制限 Level 3 の references/ が今回の主役。公式にも「Skill にバンドルできるコンテキスト量は 事実上無制限 」と書かれています。ファイルシステム上に置いておくだけなら、いくらでも参照資料を増やせるということです。 実際のコード例: SEO レビューエージェント 具体的にどう使うか、このプロジェクトの SEO レビューエージェント（ .claude/agents/seo-reviewer.md ）の例を見せます。やっていることは単純で、人間が資料を手元に広げながら作業するのと同じです。「まずタイトル基準のファイルを読んで評価し、次にパワーワード一覧を読んでタイトルを生成する」という流れを、エージェントの定義ファイルに書いておく。 ### Phase 3: SEO価値の評価 **参照資料の読み込み**（Readツールで取得）: - `docs/references/seo/title-optimization-guidelines.md` - `docs/references/seo/meta-description-guidelines.md` - `docs/references/seo/spark-framework.md` ### Phase 4: タイトル生成 **参照資料の読み込み**: - `docs/references/seo/three-patterns.md` - `docs/references/seo/power-words.md` Phase 3（評価）と Phase 4（生成）で、それぞれ必要なファイルだけを Read で取得しています。全部を一度にロードしない。これが Progressive Disclosure の実践です。 なぜこれが効くのか 不要な references はトークン消費ゼロ : ファイルシステム上にあるだけで、Read されなければコンテキストを使わない 毎回 Web 検索しなくていい : 一度蒸留した references を再利用するだけ。コンテキストが作業に使える 品質が安定する : 検証済みのデータが毎回同じように注入されるので、出力のブレが減る Before/After: 実際にどう変わったか ここまで仕組みの話をしてきたので、実際に変わった部分を見せます。 SEO タイトル提案の比較 一番わかりやすいのが SEO タイトルの提案。同じ記事に対して、references なしとありで出てきたタイトル案を比べてみます。 references なし references あり タイトル案1 Claude CodeのAI出力がイマイチ？専門外の知識もAIに使わせる3ステップ Claude Codeの出力品質を3倍高める調査→構造化→注入パイプライン【2025年版】 タイトル案2 Claude Codeで調査結果を活用する方法：研究データを構造化してAI出力を改善 Claude Codeで専門外知識をAIに使わせる：参考資料レベルの出力を得る方法 タイトル案3 AIに専門知識を注入する仕組み：調査→構造化→注入のパイプライン設計 【2025年版】Claude Code研究パイプライン完全ガイド：SEO・マーケ分析を自動化 references なしだと、タイトル案1は現在の記事タイトルをそのまま返してきました。全体的に「内容の説明」にとどまっています。一方、references ありでは SPARKフレームワーク（キーワード前方配置）、パワーワード（「3倍」「完全」「自動化」）、文字数コントロール（30〜40文字）が適用されて、検索意図別に3パターン出てきています。 ライティングレビューでの変化 SEO タイトル以外で一番変化を感じたのが、ライティングレビューです。レビューの観点（AI っぽさ検出、技術ライティングルール、チェックリスト）をそれぞれ調査して references に入れたら、具体的な指摘が出るようになりました。「文章が冗長です」みたいな曖昧なフィードバックではなく、「『様々な』は具体的な表現に置き換えてください」という粒度になった。 HTML 図解の配色が安定した テキスト以外でも変化がありました。Claude に HTML 図解を作らせると、毎回グラデーションつけてくるんですよ。「AI が図解って言われるとグラデーション使いたがるよね」って気づいた瞬間、これ前提を共有できてないだけだなと。デザインガイドラインを references に入れたら、配色が一貫するようになりました。references はテキスト系の作業だけじゃなく、生成系の出力にも効きます。 正直な課題 ただし、全部がうまくいったわけじゃありません。 ライティングの references を詳細に作りすぎて、修正を盛り込むと逆に AI っぽさが出るという課題がありました。references の粒度は「詳しすぎず、粗すぎず」のバランスが大事で、ここはまだ試行錯誤中です。この話は次のセクションの「落とし穴4」で詳しく触れます。 ハマりどころ・気をつけるポイント この仕組みを作る過程で、何回かハマりました。同じ落とし穴にハマらないように共有しておきます。 落とし穴1: 調査資料が膨大すぎて活用できない 調査資料が増えたのはいいけど、全然活用できない瞬間がありました。 /research は網羅的に集めてくれるから、 docs/research/ にファイルがどんどん溜まっていく。でも膨大すぎて検索がうまくいかないし、「あの情報どこだっけ？」が頻発した。 解決策として、YAML Frontmatter で各ファイルにメタデータを付けたり、 docs/research/README.md をインデックスとして活用するようにしました。調査資料はそのままでは使えない。検索性を考えた整理が必要です。 この辺の話は、こちらの記事（ Claude Code設計術：AIフレンドリーなドキュメント管理 ）で解説をしています。 落とし穴2: SKILL.md に全部詰め込んで肥大化 最初は references を使わず、SKILL.md に全部書いてました。チェックリストも基準もコード例も全部。当然肥大化して、Skill の実行が遅くなるし、Claude が指示を見落とすことも増えた。 公式にも「SKILL.md は500行以下に抑えて、詳細なリファレンスは別ファイルに移動する」と 推奨されています 。SKILL.md はあくまで「全体の流れと、どの references をいつ読むか」を書く場所。詳細は references/ に分離してコンテキストをスリムに保つのが正解でした。 落とし穴3: references を置いたのに読まれない references/ にファイルを置いて満足してたら、Skill が全く読んでくれなかったことがあります。SKILL.md から明示的にリンクしないと、Claude はそのファイルの存在を知らないんですよね。 対策はシンプルで、SKILL.md に「Phase 3 でこのファイルを Read する」と明記するだけ。「何を」「いつ」読むかを書いておけば、Claude はちゃんと読みに行ってくれます。 落とし穴4: references が詳細すぎると逆効果になることも 前のセクションで触れた課題の詳細。ライティングの references を作り込みすぎて、AI がそれを機械的に適用した結果、逆に AI っぽい文章になってしまいました。 試行錯誤してわかったのは、 出力したいものによって references の粒度を変える必要がある ということ。 レビュー基準（seo/, review/） → 詳細にするほど評価の一貫性が上がる。チェックリストや評価基準は具体的であるほど良い スタイルガイド（writing/） → 粗めにしないと AI がガイドを機械的に適用して AI っぽさが出る。「方向性」を示す程度にとどめる つまり「判定するための基準」は詳細に、「創作のためのガイド」は粗めに。この使い分けが大事でした。 専門外こそ効く理由 この仕組みを作って回してみて気づいたのは、技術リファレンス（ claude/ ）の管理よりも、マーケティング分析や SEO の references の方が圧倒的に価値があったということです。技術的なことは自分で判断できるから、references がなくてもなんとかなる。でもマーケティングのフレームワークや SEO のパワーワード一覧は、references がなければ AI もまともな分析ができなかった。 実際、ブログの PV データに対してマーケティング分析をかけたとき、 /research で調査した BCG マトリクスや Pareto 分析の手法を references として注入したら、207記事のデータから「上位20%の記事が64.7%のPVを生んでいる」「カテゴリ別の投資判断」みたいな分析が出てきた。その分析が正しいかどうかは僕には完全にはわからない。でも「KPI 指標に基づいてこう判断した」という根拠が付いているから、参考資料として読める。「なんとなく AI が言ってること」と「根拠付きで AI が分析したこと」では、信頼度がまるで違う。 自分が詳しくない領域こそ、この仕組みが一番効く 。やってみて初めて実感しました。 実際、このプロジェクトで管理している references のカテゴリはこんな感じです。 カテゴリ ファイル数 用途 seo/ 9 SEO タイトル・メタディスクリプション基準 review/ 9+ レビュー評価基準 claude/ 5 Claude Code 拡張のベストプラクティス 技術リファレンス（ claude/ ）はエンジニアとして自然に管理できます。でも seo/ は、 /research で調査して構造化したからこそ作れたもの。そしてそのリファレンスを Skill に注入するだけで、AI の出力が「根拠のある」ものに変わった。 専門家じゃなくても、調査して構造化すれば、その領域の知識を AI に正確に使わせることができる。 まとめ 今回の記事のテイクアウェイです。 最小行動から始める : まずは2つのプロンプト（「調査して保存」→「参照して実行」）を試してみる。繰り返すうちに仕組み化したくなったら、Skill に組み込む references の粒度は用途で変える : 「判定するための基準」は詳細に、「創作のためのガイド」は粗めに 専門外の領域こそ、この仕組みの恩恵が大きい : 自分で判断できない領域に検証済みのナレッジを注入することで、AI の出力に根拠が付く。正しさの保証はできなくても、「根拠のある参考資料」として活用できるレベルになる 改めて、最初にやってほしいことを書いておきます。 ○○のベストプラクティスについて調査して、 docs/references/xx/yy.md として保存して docs/references/xx/yy.md を参照して、 これを××してください 思いつく例があれば、まずこの2つを試してみてください。繰り返すうちに「これ Skill にしたいな」と思えたら、その先のパイプラインを作ってみる。そんな感じで始めるのがいいんじゃないかなと思います。 ほなまた〜 参考リンク 公式ドキュメント Claude Code Skills 公式ドキュメント Equipping agents for the real world with Agent Skills Effective Context Engineering for AI Agents Best Practices for Claude Code 関連ブログ（SIOS Tech Lab） Claude Code Skills 実装ガイド：ローカルツールをスムーズに統合する方法 Claude Code: 公式MCPを補完するSkills設計パターン Claude Codeの調査品質がバラバラ？：/researchで解決する方法 Claude Code /research の待ち時間をゼロに：Skill × サブエージェント構成 Claude Code設計術：AIフレンドリーなドキュメント管理 Claude Codeが遅い？毎回検索をやめて実行速度を劇的改善 CLAUDE.md効かない？ドメイン注入を設計思想から見直す ご覧いただきありがとうございます！ この投稿はお役に立ちましたか？ 役に立った 役に立たなかった 0人がこの投稿は役に立ったと言っています。 The post Claude Codeに専門知識を仕込む：調査→構造化→注入の設計パターン first appeared on SIOS Tech Lab .

本ブログは 株式会社 Sumarch 様 と Amazon Web Services Japan 合同会社 が共同で執筆いたしました。 みなさん、こんにちは。AWS ソリューションアーキテクトの森です。 Web サービスを運営する上で、セキュリティ対策とパフォーマンスの両立は重要な課題です。特に SaaS 事業者にとって、悪意ある攻撃からサービスを守りながら、正規ユーザーに快適な体験を提供することは、ビジネスの成否を左右する重要な要素となっています。 従来のセキュリティ対策では、攻撃トラフィックがアプリケーション層まで到達してしまい、サーバーリソースを消費してしまうという問題がありました。その結果、CPU 使用率が逼迫し、正規ユーザーのレスポンスタイムが悪化するといった事態も発生していました。また、スクレイピングボットや SQL インジェクション攻撃などの脅威に対して、十分な防御策を講じることが困難でした。 今回は不動産物件検索システムを運営する株式会社 Sumarch 様が、AWS WAF を段階的に導入し、数万件以上の攻撃をブロックしながら、システムのパフォーマンスを向上させた事例を紹介します。 株式会社 Sumarch 様の状況と課題 株式会社 Sumarch 様は、不動産物件検索システムである「 ハウスボカン 」を運用されており、以下のような課題に直面していました。 セキュリティ脅威の増大 突発的な DDoS 攻撃により、通常時の約 10 倍のトラフィックが発生していた スクレイピングボットによる大量のデータアクセスが発生し、管理する物件データに対する攻撃リスクがあった SQL インジェクション攻撃の試行が頻繁に観測され、データベースのセキュリティに懸念があった パフォーマンスの悪化 CPU 使用率が 100% に到達し、レスポンスタイムのスパイクする事象が発生していた 現在のレート制限設定では、画像ファイルなどの静的リソースも含めたリクエストカウントにより正常ユーザーもブロックされる事象が発生していた 攻撃パターンが不規則で複数サーバーから実行されるため、特定 IP アドレスでのブロックが困難な状況であった そこで AWS WAF を活用したセキュリティ強化により、これらの課題を解決することになりました。 ソリューション 株式会社 Sumarch 様は、AWS WAF を活用した多層防御アーキテクチャを採用し、以下のような構成を実現しました： 包括的なセキュリティルール構成 AWS Managed Rules for AWS WAF と独自ルールを組み合わせ、SQL インジェクション、ボット攻撃、DDoS 攻撃など多様な脅威から保護し、最新の脅威情報への自動対応と運用負荷の削減を実現 Bot Control マネージドルールグループの活用 機械学習を活用した高度なボット検出により、悪意あるスクレイピングボットを効果的にブロックしながら、SEO に重要な正規の検索エンジンボットは適切に許可 Amazon CloudWatch との統合 AWS WAF によるブロック数の推移、ルール別のブロック統計、地域別の攻撃パターンをリアルタイムで可視化し、迅速な対応と継続的な最適化を実現 段階的導入アプローチの重要性 AWS WAF の導入では、サービスへの影響を最小限に抑えるため、段階的なアプローチが重要です。本番環境での使用前にマネージドルールグループのテストとチューニングを行うことで、正規ユーザーへの影響を回避できます。 今回の事例では、基本的なセキュリティルールから開始し、Bot Control を監視モードで導入してボット検出精度を検証、CloudWatch メトリクスによる効果分析を経て、最終的にカスタムルールを追加することで改善を実現しました。 導入効果 AWS WAF の導入により、セキュリティとパフォーマンスの両面で改善を実現しました。 セキュリティ向上 2 ヶ月間で 92,000 件以上の攻撃をブロック スクレイピングボット、SQL インジェクション攻撃などを自動検出・防御 正規の検索エンジンボットは適切に許可し、SEO への影響を回避 パフォーマンス改善 CPU 使用率が 100% に到達する事象の解消 レスポンスタイムを最大 30% 改善 お客様の声 AWS WAF の段階的な導入により、セキュリティとパフォーマンスの両立を実現できました。Bot Control マネージドルールグループと独自ルールの組み合わせにより、CPU 使用率が 100% に達する課題が解消され、レスポンスタイムも改善しました。AWS Managed Rules for AWS WAF により、数万件件以上の攻撃を自動的にブロックしながら、正規ユーザーには快適な体験を提供できています。Amazon CloudWatch との統合で攻撃パターンの可視化とリアルタイム監視が可能になり、少人数のエンジニアチームでも効率的にセキュリティ対策を運用できる AWS WAF は、当社にとって必須のサービスです。 まとめ 株式会社 Sumarch 様の事例では、AWS WAF の段階的導入により、数万件以上の攻撃をブロックしながら、CPU 使用率の逼迫を解消し、レスポンスタイムを最大 30% 改善することに成功しました。 成功の要因は、段階的な導入アプローチによるサービスへの影響最小化、AWS Managed Rules for AWS WAF による最新脅威への自動対応、CloudWatch 統合による継続的な監視と最適化です。これにより、セキュリティ強化と運用負荷削減を同時に実現し、高い投資対効果を得られています。 本事例が、Web アプリケーションのセキュリティ強化をご検討中のお客様の参考になれば幸いです。AWS WAF を活用したセキュリティ対策にご興味をお持ちの方は、お気軽にお問い合わせください。 株式会社 Sumarch（左から）： 杉田 昌隆 様 佐々木 正男 様   Amazon Web Services Japan 合同会社： アカウントマネージャー 植木 輝（右端） ソリューションアーキテクト 森 瞭輔（左端） ソリューションアーキテクト 森