こんにちは、NTTドコモビジネス情報セキュリティ部です。 NTTドコモビジネスを含めたドコモグループでは今年も現場受け入れ型インターンシップを開催いたしました。 情報セキュリティ部でも5つのポストに対して8人のインターンシップ生に来ていただき、2週間にわたるプログラムに取り組んでいただきました！ インターンシップ生の目線で、ポスト紹介や体験した業務内容、振り返りをまとめてもらいました。 この記事では、それらをポストごとにご紹介します。 インターンシップ生目線のよりリアルな体験記を通して、次回以降に応募を検討される方の一助となれば幸いです。 【D1】CSIRTでのサイバー攻撃への対応実践と高度分析 ポスト紹介① 体験した業務内容① 演習1日目 演習2日目 振り返り① ポスト紹介② 体験した業務内容② Linuxのフォレンジック演習 Windowsのフォレンジック演習 振り返り② 【D10】CSIRT運用業務の効率化に向けたDX化 ポスト紹介 体験した業務内容 振り返り 【D11】CSIRTで脅威インテリジェンスをハンドリングするセキュリティエンジニア ポスト紹介 体験した業務内容 振り返り 【D12】ネットワークセキュリティ製品を活用したデータ/脅威分析、実装および運用高度化 ポスト紹介 体験した業務内容 NDR製品を用いた模擬攻撃の詳細調査 NDR製品における一次調査の手順書作成 振り返り 【D13】攻撃者視点で社内防御力を高めるセキュリティエンジニア ポスト紹介 体験した業務内容 ペネトレーションテストの実施とWriteup作成 改善提案表の作成 MITRE ATT&CKマッピング 振り返り おわりに 【D1】CSIRTでのサイバー攻撃への対応実践と高度分析 D1ポストは、2つのチームの合同ポストです。それぞれのチームの業務を体験していただきました！ ポスト紹介① EDR（Endpoint Detection and Response） 1 やSIEM（Security Information and Event Management） 2 からのアラート対応、および社内外から報告されたインシデントへの対応が体験できるポストです。インターンシップでは、隔離された検証環境において模擬攻撃を実施し、EDRのアラート精度を検証しました。 体験した業務内容① MITRE社が開発し、現在はApache Software Foundationにおいて開発が進められている攻撃シミュレーションツール「 Apache Caldera 」を用い、さまざまな攻撃手法を再現しました。そのうえで、「どのような操作やコマンドがEDRに検知されるのか」「逆に、どのような挙動が検知されにくいのか」という観点から分析をしました。 演習環境は、攻撃するためのVM1台と、攻撃対象となるVM2台で構成されていました。 演習1日目 1日目は、模擬攻撃によって発生したEDRのアラートを分析し、インシデント対応を体験しました。 具体的には、提示された4件のアラートについて、以下の観点から調査・検討しました。 なぜアラートが発生したのか EDRはどのような挙動を検知したのか どのような脅威が考えられるのか 実際の運用ではどのような対応が必要になるのか 単にアラートの内容を確認するだけでなく、想定される脅威や必要となる対処を考えることで、インシデント対応担当者に求められる考え方を学ぶことができました。 演習2日目 2日目は、Apache Calderaを用いてオリジナルの攻撃シナリオを作成し、その挙動がEDRにどのように検知されるのかを検証しました。 攻撃シナリオを自ら設計することで、攻撃側の視点と防御側の視点の両方からセキュリティ対策を考えることができました。 また、実際にシナリオを実行して検知結果を分析することで、EDRがどのような振る舞いを重視して監視しているのか、理解を深めることができました。 今回追加した攻撃シナリオの例は以下のとおりです。 ネットワークをスキャンして、隣接IPを調査 見つけたIPに対してポートスキャン cuppをcloneして、パスワードリストを作成 作成したリストを使ってHydraでログイン試行 特定したパスワードでログイン 振り返り① 今回の演習を通じて、アラート対応業務への理解を深めることができました。実際の運用では重大なインシデントが発生することは多くなく、日々発生するアラートの中には誤検知が多いことを学びました。このことから、多数のアラートの中から誤検知を適切に判断し、迅速に対応することの重要性を理解しました。また、IoC（Indicators of Compromise） 3 だけでなくIoA（Indicators of Attack） 4 に着目した検知の考え方にも触れ、どのような振る舞いをルール化すれば効果的な検知につながるのかを考える良い機会となりました。 今回の演習から、実際の環境におけるEDRの具体的な使い方や運用方法を学ぶことができました。また、自ら攻撃シナリオを作成し、発生したアラートを調査するという一連の流れを経験しました。この過程で、攻撃側と防御側が相互に技術を高め合うことの重要性を確認できました。今後は、攻撃側と防御側、双方の視点から捉えて技術を高めていきたいと思います。 EDRを実際に使用することで、これまで不明瞭であったCSIRTの具体的な業務プロセスについて理解を深められました。また、実際の対応においては、Red Teamの視点を持つことの重要性と、チーム内での連携やコミュニケーションが不可欠であることを学びました。今回の経験を踏まえ、今後の学習においてもApache Calderaを日常的に活用していきたいと考えています。 ポスト紹介② Blue Teamの一員として、デジタルフォレンジック調査や脆弱性管理などを実施する業務です。インターンでは、フォレンジック演習に取り組みました。 体験した業務内容② 本ポストの業務では、LinuxとWindowsを対象としたフォレンジック演習に取り組みました。 Linuxのフォレンジック演習 Linuxのフォレンジック演習では、DrupalのRCE（Remote Code Execution）脆弱性 を悪用した攻撃を題材として扱いました。RCEは、攻撃者がネットワーク越しに対象サーバやアプリケーション上で任意のコードを実行できてしまう脆弱性です。 演習では、Apacheのアクセスログや認証ログ、コマンド実行ログなどを調査し、攻撃の痕跡や侵入後の活動を分析しました。 集めた攻撃の証拠を時系列で確認することで、攻撃者によるコマンド実行や権限昇格、バックドア用のユーザ作成による永続化、Webシェルの設置まで、攻撃の流れを追跡しました。 Windowsのフォレンジック演習 Windowsのフォレンジック演習では、被疑端末から取得した各種アーティファクト（システムや利用者の活動履歴を示すデータ）を調査しました。 具体的には、ファイル操作の履歴を確認できる「MFT（Master File Table）」、Windowsのイベントを記録する「イベントログ」、実行されたプログラムの情報が残る「Prefetch」や「Amcache」、ユーザ操作の痕跡を確認できる「UserAssist」、ネットワーク通信を分析する「PCAP（Packet Capture）」などを用いて、不審な活動の有無を分析しました。 その結果、ユーザ端末上でコードエディタ製品の正規ツールを装ったマルウェアが実行され、端末のユーザ情報やIPアドレスなどの情報が攻撃者側へ送信されていたことを確認しました。 振り返り② LinuxおよびWindows環境のフォレンジック演習を通じて、インシデント発生時にどのログを優先的に確認すべきか、またどのような観点で調査を進めるべきかを再確認できました。時系列で事象を整理する重要性は理解していましたが、ログから痕跡を効率的に見つけ出す視点も重要であると学びました。特にWindowsでは、UserAssistだけでなくPrefetchやAmcacheなど複数のアーティファクトを組み合わせて分析することで、プログラムの実行時刻や実行回数をより正確に把握できることが印象的でした。答え合わせや他の参加者との議論を通じて、知らなかったアーティファクトや調査手法についても学ぶことができ、大変有意義な経験となりました。 演習を通じて、フォレンジック調査に必要となる各種ツールの用途や使用方法を学ぶとともに、実際の解析に至るまでの具体的な業務フローを把握できました。また、社員の方からの解説を聞く中で、ログから抽出・推測できる情報や調査手法について、自分のフォレンジックに関する知識は十分でないと痛感しました。今回の経験を踏まえ、今後はログ分析やフォレンジックに関する知見をさらに広げ、継続して学習に取り組みたいと考えています。 フォレンジック演習を通じて、フォレンジックの実務についてより具体的な理解を得ることができました。特に、参加者3名がそれぞれ異なる手法を用いて調査を進めている点を確認でき、調査における多角的な視点の重要性を認識しました。また、実際の過程を通じて、OSの仕組みをはじめとする、自身に不足している知識が明確になりました。今後はこれらの領域についても継続的に学習を進め、技術的な理解を深めていきたいと考えています。 【D10】CSIRT運用業務の効率化に向けたDX化 ポスト紹介 セキュリティオペレーションの効率化と高度化を目的とした開発業務を体験しました。 具体的には、①アラートメールの自動チケット化と、②問い合わせ時の通知機能の自動化に取り組みました。 体験した業務内容 まず、①アラートメールの自動チケット化について説明します。 メール受信ボックスにセキュリティアラートメールが届いた際に、メールの内容を抽出してチケット管理システムに自動起票し、添付ファイルを保管領域に保存したうえで、コミュニケーションツールにアラートの発生を知らせる通知システムを開発しました。 今回は、インシデントレスポンスに必要な情報かどうかという観点から、以下の3種類のメールごとに実装を分けました。 初報メールの場合、新たにチケットを作成し、通知する 更新メールの場合、既存のチケットを更新し、通知する 週間レポートメールの場合、何もせずに処理を終了する 本格的なシステムの作成前に、まず2人で要件定義の洗い出しを行いました。 これまで要件定義の経験がなかったため、実際に作成しながら学ぶことが多くありました。 特に、エラーなどの異常系をどこまで想定して記載すべきかについては、2人で悩みながら検討を重ね、試行錯誤しながら完成させました。 要件定義を作成したことで、今後何を作成しなければならないのかが明確になりました。 その後は、要件定義の内容を基に各自でフローチャートを作成し、処理の流れや実装内容への理解を深めることができました。 技術的に不明で調査が必要な箇所には吹き出しでメモを残し、開発前にモックアップを作成して技術調査をしました。 本実装では、これまで整理してきた要件や調査結果を基に、自動化ツールを用いてワークフローを作成しました。 アラートメールに含まれる情報を抽出し、チケット管理システムへ必要な情報を自動で起票するとともに、コミュニケーションツールへの通知を自動化する仕組みを構築できました。 実装の過程では、初めての自動化開発ということもあり、エラー対応や処理の実装方法に悩む場面が多くありました。 しかし、その都度原因を調査し、設定や処理内容を見直しながら試行錯誤を重ねることで、ひとつひとつ課題を解決できました。最終的には要件を満たすワークフローを完成させることができ、技術的な成長を実感するとともに、大きな達成感を得ることができました。 次に、②問い合わせ時の通知機能の自動化について説明します。 ①で自動化ツールを用いた開発への理解を深めた後は、それまでに学んだ知識や経験を活かし、チケットシステムの利用者から送信される問い合わせをフォームとリストで管理し、新たな問い合わせが届いた際にチケットシステムの運用担当者へ通知するシステムを開発しました。 前回の開発で得た知見を活用しながら設計・実装を進めることで、サービス間の連携や自動化について、さらに理解を深めることができました。 また、問い合わせフォームが送信されると、その内容が管理リストに投稿されます。 このとき、コミュニケーションツールへの通知だけでなく、状態ステータスも変更する仕様を実装しました。 新規の問い合わせが登録されると、問い合わせ内容を含む通知が関係者へ自動送信される仕組みを実装しました。 また、通知内のアクションボタンを操作することで、リストで管理している問い合わせの状態を「受付」から「対応中」へ、「対応中」から「完了」へ更新できるようにしました。 これにより、問い合わせ対応状況の管理を効率化し、運用担当者が迅速に対応できる仕組みを実現できました。 振り返り 今回のインターンシップで、会社での開発は、他のチームの方々や開発したツールを使用する利用者、今後新たに機能を拡張する他の開発者のことまで考えながら進めるものであると、身をもって実感しました。特に、実装方法が複数考えられる場合に、どのパターンを選ぶかの判断基準が利用者や他の開発者にあることを知ることができ、インターンシップに参加してよかったと感じました。 2週間のインターンシップを通して、期間内に成果物を完成させるための時間・スケジュール管理の必要性や、業務を進めるうえでの情報共有・コミュニケーションの重要性、トライアンドエラーを繰り返して問題を解決する力を理解し、身につけました。この経験を活かし、さらなる自己研鑽を進め、応用や拡張にも適応できる人間に成長したいと考えています。 【D11】CSIRTで脅威インテリジェンスをハンドリングするセキュリティエンジニア ポスト紹介 サイバー攻撃による社内システムへのインシデント被害の最小化と未然防止をミッションとしている、セキュリティエンジニアのポストです！ チーム内で行っている業務はさまざまですが、代表例として、公開情報から脅威アクターの動きを観測しています。 また、日々更新される脆弱性情報の中からリスクの高いものをレポーティングし、関連部署へシステムのバージョン管理やアップデートを促しています。 体験した業務内容 社内システムに関連する脆弱性が公開された際に、他部署へ注意喚起するためのインテリジェンスレポートを、ClaudeのSkillを用いて自動的に作成できるよう実装しました。 フロンティアAIの登場により脆弱性の報告数が増加し、対応に追われている組織も多く、私が参加したチームでも同様の課題を抱えていました。 この課題を解決するために、取り上げるに値する脆弱性のスコープごとにSkillをオーケストレーションすることで、網羅性を確保しつつ利用者の調査業務の時間短縮につながるように設計した点がポイントです。 実際にこのSkillを使用することによって、業務上で改善された点は3つあります。 1つめは、インテリジェンスレポートの品質の担保です。これまでは各メンバーがそれぞれLLMを用いてレポートの草案を作成していましたが、プロンプトの与え方や参照ソースの選び方がメンバーごとに異なるため、同じCVEを扱っても出来上がる草案の粒度や観点にばらつきが生じていました。 今回作成したSkillでは、収集すべき情報源・記事の構成・文体指針をあらかじめ定型化したことで、誰が実行しても一定の水準を担保できる状態にしました。 2つめは、レビュー工数の削減です。従来はレビュアーが草案を受け取ってから複数回の指摘・修正のやり取りが発生していましたが、Skill側で文体チェック、参照リンクの生存確認、未確認項目の可視化までを自動で行うようにしたため、レビュー工数が実質1回で済むようになり、レポート作成全体に要する時間が大幅に短縮されました。 最後に、作成コストの安さです。1本のインテリジェンスレポートを生成するのにかかる費用はOpus 4.7で500〜600円程度に収まっており、頻繁に運用しても負担にならない水準を実現できました。 振り返り 本課題を始める前に、脅威インテリジェンスとは何かを知るため、5つのSTEPからなる総合演習で構成されるコースワークに取り組みました。 その際、インテリジェンスという抽象的で説明しがたい概念を理解するため、アメリカ統合参謀本部が公開している「JP 2-0 5 」を読みましたが、「インテリジェンスとは何か」がますます理解できなくなり困りました。 理解が及ばない部分については、抽象的な概念をつかむために脅威インテリジェンスの教科書を読み込みました。インターンシップ期間中は四苦八苦しましたが、基礎的かつ重要な事項を、苦しみながらも自分の言葉で表現できたときはとても嬉しかったです。 本課題では、チームの日常業務の効率化とリスクの明確化を目標に、ClaudeのSkillでインテリジェンスレポートの自動生成に取り組みました。 文章だけで見ると「あまりたいした実装ではないのでは……？」と思われるかもしれません。しかし今回の実装は、現場でも「何が課題なのか、何ができると嬉しいのか」を要件定義しきれていない暗黙知を扱うものであり、私個人で完結できる内容ではありませんでした。 そのため、メンターの方々や上長を含むチームメンバーと議論を重ねながら進める必要があり、相応の時間を要する難易度の高い取り組みとなりました。 要件を定義しづらい課題にチームメンバーと協働しながら取り組んだ経験は、これまでの個人開発では決して得られないものであり、本課題を通して課題設定力と、短い期限のなかで冷静に優先順位を判断し物事を推進する力が身についたと感じています。 最後に、本インターンシップ全体の学びを書いて終わりたいと思います。脅威インテリジェンスは、科学的な検証によって確実性が保証される領域ではありません。仮説から捕捉できた脅威はエッジケースかもしれませんし、逆に何もわからなくても、それが現時点でのベストエフォートかもしれません。 だからこそ、直感的な洞察と論理的な分析の双方から解釈した情報を意思決定に活かすことがアナリストの責務ではありますが、これを成し得るには蓋然性を正しく判定するためのプロセスを踏み続ける必要があり、この営みを継続することの難しさを学びました。 【D12】ネットワークセキュリティ製品を活用したデータ/脅威分析、実装および運用高度化 ポスト紹介 本ポストでは、新たに導入するセキュリティ製品の評価や、組織で活用していくための運用支援業務を行っています。 その中で私は、ネットワーク上の不審な通信を検知・分析するNDR（Network Detection and Response）において、模擬攻撃を詳細に調査し、その知見を誰もが活用できるよう手順書の作成に取り組みました。 体験した業務内容 NDR製品を用いた模擬攻撃の詳細調査 NDRで検知されたアラートの詳細調査を実施しました。アラートに関連する通信を条件で絞り込みながら確認し、実際にどのような攻撃行動が行われていたのかを分析しました。 調査を通じて、得られた情報をもとに攻撃者の行動を推測し、攻撃のシナリオを組み立てながら通信内容を分析することの重要性を学びました。 上記の図は、アラートに関連する通信をSQL文を用いてフィルタリングした結果です。 NDR製品における一次調査の手順書作成 NDRでアラートが発生した際に、一次調査で使用する手順書を作成しました。手順書の作成にあたっては、製品の機能や操作方法を整理するだけでなく、実際にアラートが発生した際の調査の流れを想定しながら内容を検討しました。 また、利用者が必要な情報に迷わずたどり着けるよう、実際の運用で求められる確認事項や判断材料を意識して文書化を行いました。 上記の図は、実際に作成した手順書の一部です。手順書の作成にあたっては、実際のNDRの操作画面のスクリーンショットを使用し、図中の確認箇所をナンバリングして本文との対応関係を明確にしました。 また、模擬攻撃の詳細調査を実施した際に理解や判断に迷った箇所については、調査時の観点や確認ポイントを補足するなど、利用者が迷わず調査を進められるよう工夫しました。 振り返り 今回のインターンシップでは、セキュリティ製品そのものだけでなく、組織における運用についても学ぶことができました。特に手順書の作成では、操作方法をまとめるだけでなく、その情報がどのように活用されるのかを意識する必要がありました。 また、実際の運用では他組織との連携も求められるため、利用者の視点で必要な情報を整理し、分かりやすく伝えることの重要性を学びました。 今後は、本インターンシップで得たセキュリティ製品の知識や運用設計の考え方を活かし、実際の運用を見据えたシステム設計や仕組みづくりができるエンジニアを目指したいと考えています。 【D13】攻撃者視点で社内防御力を高めるセキュリティエンジニア ポスト紹介 NTTドコモビジネス社内の組織やサービスに対して脅威ベースのペネトレーションテストを実施し、セキュリティ対策の状況をRed Teamの立場で継続的にチェックする業務を行っているチームに所属させていただきました。 具体的には、攻撃ツールの検証や環境構築、攻撃シナリオの整備、改善提案などに従事しました。 体験した業務内容 ペネトレーションテストの実施とWriteup作成 VulnHubから入手した脆弱なLinuxマシン2台に対してペネトレーションテストを実施し、Writeupを作成しました。 ペネトレーションテストは、情報収集、脆弱性調査、初期侵入、権限昇格の順で行いました。 1台目は、DrupalというCMS（Content Management System） 6 のRCE脆弱性を悪用して初期侵入を実施し、SUIDの設定不備を悪用して権限昇格をしました。 2台目は、2台目は、WordPressのプラグインの脆弱性を悪用してサーバ上のファイルを読み取るLFI（Local File Inclusion） によりパスワード情報を取得できました。LFIは、本来アクセスできないサーバ内のファイルを読み取れてしまう脆弱性です。 その後、保存されていたパスワードをリバースブルートフォースすることで侵入できました。 また、実施した攻撃手法のうち、チームのナレッジ集になかったものを追加させていただきました。 改善提案表の作成 発見した脆弱性について、仮想の会社で脆弱性を悪用された際に想定されるリスクや改善案などをまとめた改善提案表を作成しました。 メンター社員の方からアドバイスをいただきながら、実際の業務に近い改善提案をできました。 MITRE ATT&CKマッピング MITRE ATT&CK（Adversarial Tactics, Techniques, and Common Knowledge） は、サイバー攻撃者が用いる戦術や攻撃手法を整理したナレッジベースです。 本演習では、実施した攻撃をMITRE ATT&CK Navigator上でマッピングし、どのような攻撃手法が用いられたかを可視化しました。 濃い赤は2台に共通していた攻撃手法、薄い赤は片方のマシンでのみ使用した攻撃手法です。 振り返り 今回のインターンシップを通じて、本ポストでは攻撃を成功させるための技術力だけでなく、運用側にどのような改善を促すかを考える提案力も重要であると学びました。特に改善提案表の作成では、場当たり的な対策を提示するだけでなく、脆弱性を生まないために業務プロセスをどのように改善していくべきかまで踏み込んで考えることができました。 また、Writeupの作成では、相手に伝わりやすいレポートの作成方法についても学ぶことができました。 おわりに 本記事では、2週間のプログラムに取り組んでいただいたインターンシップ生の皆さまに、それぞれのポストでの業務と、そこで得た学びを綴っていただきました。ご多忙のなか快くご協力いただき、ありがとうございました。 本記事を読んで少しでも興味を持たれた29卒以降の方は、ぜひ来年度のインターンシッププログラムへご応募ください。皆さまとお会いできることを楽しみにしています！ Endpoint Detection and Response。PCやサーバなどの端末上の動作を継続的に記録・監視し、不審な挙動の検知と、その後の調査・対応を支援する仕組みです。 ↩ Security Information and Event Management。各種機器やソフトウェアが出力するログを一元的に集約し、相関分析によって脅威の兆候を検知する仕組みです。 ↩ Indicator of Compromise（侵害指標）。マルウェアのハッシュ値や通信先のIPアドレス・ドメインなど、侵害が発生したことを示す個別の痕跡を指します。 ↩ Indicator of Attack（攻撃指標）。個々の痕跡ではなく、攻撃者が目的を達成するまでにとる一連の振る舞いに着目した指標で、進行中の攻撃の兆候を捉えることを狙いとします。 ↩ Joint Publication 2-0「Joint Intelligence」。アメリカ統合参謀本部議長の指揮のもとで整備される統合ドクトリンのうち、情報（インテリジェンス）分野の基幹文書にあたります。統合作戦における情報の役割や基本原則、情報が生み出されるまでの一連のプロセスがまとめられています。文書は 統合参謀本部のサイト で公開されています。 ↩ Contents Management System。Webサイトのテキストや画像などのコンテンツを、HTMLを直接編集することなく作成・管理・公開できるようにするシステムです。本記事に登場するDrupalやWordPressがこれにあたります。 ↩

はじめに さくらインターネットのCDNサービス「さくらのウェブアクセラレータ」は、2016年10月1日にさくらのクラウドのオプションサービスとして正式提供を開始し、2026年10月で提供開始から10周年を迎えます。月間数 […]

もう入っている Chrome を、そのまま触らせる Chrome DevTools MCP は、いま普段使っている Chrome をそのまま使います。自動化用のブラウザを別に落とす手順が要らないので、入れるのはコマンド1本です。動かしてみると立ち上がってくるのは見慣れた Chrome とほぼ同じ画面で、そこの安心感が大きかったですね。 そうなると素朴な問いが1つ残ります。ブラウザも触らせたいけど、ログインが要る画面はどうするのか。先に環境を作って、そこから順に書きます。 先に1つだけ前提があります。 Node.js が入っていること です。この後のコマンドで使う npx は Node.js に同梱されているので、まっさらな Windows では叩けません。確かめたのは v22.15.0 です。 Node.js の入れ方そのものはこの記事では扱いません。普段から開発している人なら手癖で終わる話ですし、そうでない人は Claude に「Windows に Node.js を入れたい」と聞けば、いまの環境に合った手順を出してくれます。ここに書いてもすぐ古くなるところなので、そちらに任せます。 入れ方そのものに新しいところは何もないので、 公式の Get started も並べておきます。Gemini CLI や Codex、JSON で設定を書く形はそちらにまとまっています。Claude Code についてはプラグイン経由の入れ方（ /plugin marketplace add ChromeDevTools/chrome-devtools-mcp → /plugin install chrome-devtools-mcp@chrome-devtools-plugins ）も案内されていて、そちらは MCP に加えて Skills も一緒に入ります。この記事は素の MCP 登録だけで進めます。 龍ちゃん 特別な事情がない方は！Skillsも一緒に入れておいたほうがいいから公式を見ようね！ この前提を踏まえて、入れるのはコマンド1本です。 claude mcp add chrome-devtools -- npx -y chrome-devtools-mcp@latest これだけです。オプションは1つも要りません。打ったディレクトリ限定で登録されるので、どこでも使いたいなら --scope user を足します。 追加したら Claude Code のセッションを一度開き直します。開き直さないとツールが生えません。入っているかはこれで見えます。 $ claude mcp list Checking MCP server health… chrome-devtools: npx -y chrome-devtools-mcp@latest --user-data-dir=C:\Users\<ユーザー名>\.chrome-automation-profile --viewport=1400x900 --screenshot-format=webp --screenshot-quality=70 --screenshot-max-width=1400 - ✔ Connected 僕の環境はオプションを足しているので長いですが、素の登録ならもっと短く出ます。見るのは末尾の ✔ Connected だけです。ただしこれで分かるのはサーバーの疎通までで、実際に動くかは1回 list_pages を呼ばせるまで分かりません（この話は最後にもう一度出てきます）。 今回は Windows で完結させています。WSL2 や devcontainer からホストの Chrome を叩く構成は扱いません。 入ったので、何が取れるのかを先に見ておきます。自分のブログの公開ページを開いて、構造をテキストで取ってみます。 navigate_page(pageId=1, type="url", url="https://<自社ブログ>/") → Successfully navigated to https://<自社ブログ>/. ## Pages 1: SIOS Tech Lab - エンジニアのためになる技術トピックス (https://<自社ブログ>/) [selected] take_snapshot を呼ぶと、ページの構造がテキストで返ってきます。要素に番号（uid）が振られているので、座標を推定しなくても操作できるんですよね。 uid=1_0 RootWebArea "SIOS Tech Lab - エンジニアのためになる技術トピックス" url="https://<自社ブログ>/" uid=1_1 banner uid=1_218 StaticText "© 2026 SIOS Tech Lab All rights reserved." 使い分けは1行で足ります。操作するためならスナップショット、人に見せる・見た目を判断するためならスクリーンショットです。 ブラウザ操作なら、だいたい一通りできる ここまでスナップショットとスクリーンショットしか出していませんが、道具はもっとあります。公式の ツール一覧 を数えると、2026年9月の時点で57個ありました。 ブラウザ操作に関わることなら、だいたい一通りできる と思っていいです。 まずユーザー操作のほう。クリック、テキスト入力、フォームの一括入力、ドラッグ、ファイルのアップロード、キーの送信、ダイアログの応答。タブの開閉と切り替え、画面サイズやデバイスのエミュレーションもあります。人が画面でやっていることは、だいたい指示に置き換わります。 うれしいのはここからです。F12 で開く開発者ツールのタブで見ていたものは、だいたいそのまま取れます。ネットワークのリクエスト一覧とヘッダ（Cookie も入ります）、パフォーマンスのトレースから Core Web Vitals（LCP・INP・CLS）、コンソールのメッセージ。画面の見た目ではなく数字が返るので、そのまま AI に読ませて判断させられるんですよね。 いま議論中の話も1つおまけで書いておきます。ヘッド付きの Chrome を触らせても、OS のマウスカーソルは動きません。入力は CDP のレイヤで注入されるので、隣で見ている人にはエージェントがどこをクリックしたのか分からないんですよね。そこで「ゴーストカーソルを重ねて見せる」 提案 が上がっていて、実装まで済んだ PR も1本ありましたが、ページに DOM を挿し込む形は避けたいというメンテナのコメントが付いて、いまは意見を集めている段階です（2026-09-07 に確認）。この辺はすぐ動くので、気になる人は issue を直接見てください。 動くのは、普段使いとは別のプロファイル オプション無しで動くのは、chrome-devtools-mcp が自前の場所に専用のプロファイルを作ってくれるからです。これは試してみるとわかりますが、Chrome 136 以降、既定のプロファイルのままだとリモートデバッグの指定が無視されるんですよね。理由は 公式のリンク で。 要するに 普段使いの Chrome とは別のプロファイルで動く 、という前提が最初から満たされているわけです。 置き場所を自分で決めたいときだけ、 --user-data-dir で渡します。僕がそうしているのは、後から中を見られるようにしておきたかったからです。ほかにも画面サイズやスクリーンショットの形式を指定するオプションがありますが、最初は1つも要りません。要るようになったら 公式のオプション一覧 で必要なものだけ拾ってください。 専用のプロファイルには、本物のログイン状態がそのまま乗ります。フォルダごと別の PC にコピーしても、そのままでは使えない作りになっています（ここは自分では試していません）。ただこれを「安全」とは読まないでほしくて、守れているのは持ち出しだけで、同じ PC の中からは触れてしまうんですよね。だから普段使いのプロファイルと分かれているのは、動かすための条件であると同時に、被害を閉じ込める線でもあるんだと思っています。 ログイン画面に来たら、エージェントはどうするのか ここからが本題です。僕の前提は1つで、 ID とパスワードはエージェントに渡しません 。認証が要る画面を触らせたいときも、そこだけは人が打つ。その前提で指示を先に書いておきます。 実際に投げたプロンプトの末尾がこれです。 前提: ログインは人がやる — 認証画面が出たら止まって依頼する。 そう書いておくと、エージェントは認証フォームを見つけた時点で入力を試さずに止まります。止まったときの出力がこれです。 ここで止まります。**手動ログインをお願いします。** ブラウザは `<自社ブログ>/wp-login.php` を開いた状態です（`pageId=1`、入力前の1枚は取得済み）。 お願いしたいこと: 1. その Chrome ウィンドウで**ログインしてください**（ID/パスワードは私は一切触りません） 2. ⚠ ログイン後、**管理画面のまま置いておいて構いません** — 私は管理画面をスナップショットも スクショもせず、公開ページへ直接 navigate して戻します 3. 終わったら「**終わった**」と言ってください。それを合図に再開します 止まり方として効いているのは3つあると思っていて。頼みごとが1つに絞られていること（ログインして、だけ。他の判断を人に投げていない）、やらないことを明言していること（ID・パスワードには触らない、管理画面は撮らない）、再開の合図を先に決めていること（人が次に何を言えばいいか迷わない）です。 ただしこれは規約であって、強制ではありません。フォームに入力するツール自体は生きているので、絶対に触らせたくないなら、ツールの許可設定の側で落とすことになります。 画面はこれ1枚だけで、空欄のフォームです。エージェントはここに一度も触っていません。 人が返した合図は「ログインした」でした。依頼したのは「終わった」だったんですけど、今回はこれでも再開できています。 再開の1手目は list_pages にします。これも指示に先に書いておく一行です。ブラウザを開き直すと番号が振り直されることがあって、そのときは MCP 自身が「再起動されたので番号が変わった」と教えてくれます。古い番号のまま呼ぶと失敗するので、1手目は取り直しにしておくと安全なんですよね。 ついでに、採番の確認はそのまま「いま何が開いているか」の確認にもなります。 list_pages() → ## Pages 1: ダッシュボード ‹ SIOS Tech Lab — WordPress (https://<自社ブログ>/wp-admin/) [selected] ログインすると管理画面に入れます。ただ今回は中を見ていなくて、タイトル行がテキストで出ているだけで、そのまま公開ページへ戻しました。 戻した先で撮ったのがこれです。さっきと同じ URL、同じ位置で、上端に管理バーが増えているだけです。 これで受け渡しが成立しています。人が担ったのはログインだけで、その前後はエージェントが動いているんですよね。 ひとつ気をつけどころがあります。認証の先へ入るということは、 そこから先はログインした人の権限で動く ということです。読める範囲も押せるボタンも、認証した自分と同じになります。ID とパスワードを渡していないことと、任せた範囲が狭いことは別なので、管理者のアカウントで入るのか、要る権限だけのアカウントで入るのかは、触らせる前に決めておいたほうがいいです。 なお、ここで書いているのは自分たちのサイトでの話です。他社のサービスを自動で操作させてよいかは規約の話が別に要るので、この記事では扱いません。 毎回ログインし直すことになるの？ プロファイルに何が乗るのか、認証を誰が担うのか。ここまでの2つは、最後に1つの問いでつながります。ログインした状態は、どこまで残るのか。ここは層が2つあるので分けて書きます。 1つは、プロファイルに乗る Google アカウントのサインインです。こちらは残っていて、閉じて開き直しても入ったままでした。確かめたのは約8分後、約28時間後、いちばん長いところで約6日2時間後です。 もう1つは、そのサイトが自前で持っているセッションです。今回の自社ブログはこちら側で、ブラウザを閉じたらログインし直しになりました。ウィンドウを普通に閉じて（強制終了はしていません）、約25秒後に開き直しても、管理バーは消えていました。 なぜ残るのか、なぜ残らないのかは追っていません。ログイン状態がどこに保存されるかで変わるところなので、どちらも振る舞いだけ書いています。 残らないなら残るようにしたい、と思うところですが、サイト側の認証情報を自分で取り出して保存する方向へは行っていません。保存した時点でそれが流出の対象になりますし、次からは人が一度も通らずに入れてしまうからです。最後の防壁となる人間の手作業が、丸ごと無くなるんですよね。動かしているあいだはブラウザを見ておいて、挙動に違和感があったり、なんかヤバいなと思ったらパスワードを変える、くらいは構えておくといいと思います。 ただ、Google のサインインだけは自分で保存しなくても残ります。人が毎回通るのはサイト側のログインのほうだけで、そのプロファイルは Google に入れる状態のまま置いてある、と思っておいたほうがいいです。 大事なのは、残らなくても認証の切り分けは成立しているということです。見返りは「次から要らなくなる」ではなく、今この1回、人が触るのはログインだけで済むということなんですよね。 じゃあ次は何を渡せるのか 冒頭の問いを回収すると、ログインが要る画面はどうするのか、答えは人が1回入って、その先を渡す、です。 渡せる仕事はまだあります。 list_network_requests で通信を、 list_console_messages でコンソールを取れるので、「この画面のここが遅い」「エラーが出ていないか」をそのまま調べさせられるんですよね。 ここで使い分けを1つ。開発の現場では、僕は Playwright のほうを使っています。テストを書く場所ですし、同じ手順を何度も回すならコードで持っておくほうが確実なので。入口は Playwright MCP で始めるブラウザ自動化 に書きました。Chrome DevTools MCP が効くのは、日常のちょっとした動作を1回やらせたいときです。わざわざ環境を作るほどではない、でも手でやるのは面倒、くらいの仕事ですね。正直、Windows に Playwright の環境を入れるのが面倒でずっと手が止まっていた、というのも僕の側の事情としてはあります。 反復するならやはり Playwright を書いたほうがいいです。楽なのは着手であって、運用ではないので。 最初の一歩は1つだけです。 claude mcp add を1本打って、「自分のブログのトップを開いて、構造を取ってみて」と頼んでみる。テキストが返ってきたら、そこから先は渡せます。 ご覧いただきありがとうございます！ この投稿はお役に立ちましたか？ 役に立った 役に立たなかった 0人がこの投稿は役に立ったと言っています。 The post Chrome DevTools MCP を Windows に入れる。ログインだけ人がやる first appeared on SIOS Tech Lab .