Zenn
Open23

Claude Code / Raycast / MCP など

Yasutaka NishiiYasutaka Nishii

Playwright MCP x Electorn

https://qiita.com/Takenoko4594/items/cc36ca3043f11ca175c1
https://qiita.com/ore88ore/items/106c851e56631045fe25
https://qiita.com/jajima/items/f0dbb1e36bc2819fbdfd

Yasutaka NishiiYasutaka Nishii

⚙️ Playwright MCPを試験環境で実装するベストプラクティス

「試験時のみ利用」という要件に最適な実装方法を検索結果 [1] [2] [3]に基づき提案します。設定の簡素化とテスト効率化が鍵です。

🔧 最小構成の実装手順

  1. テスト専用スクリプトの作成（例: test-mcp.js）

    const { startMcpServer } = require('@playwright/mcp');

module.exports = async () => {
  const server = await startMcpServer({
    port: 0, // ランダムポート割当
    mode: 'testing' // 試験モード指定
  });
  return server;
};

  2. テストランナーでの統合（Jest/Puppeteer例）

    // jest.setup.js
let mcpServer;

beforeAll(async () => {
  mcpServer = await require('./test-mcp.js')();
  process.env.MCP_URL = mcpServer.url(); // 環境変数でURL渡す
});

afterAll(() => mcpServer.close());

  3. 試験用設定の分離（playwright.config.js）

    // 試験時のみ有効化
if (process.env.NODE_ENV === 'test') {
  config.use = {
    ...config.use,
    mcpServer: process.env.MCP_URL
  };
}

📂 ファイル構成例

project-root/
├── src/
├── tests/
│   ├── mcp/
│   │   ├── test-mcp.js       # MCPサーバー起動スクリプト
│   │   └── mcp-utils.js      # 操作ヘルパー関数
│   └── e2e/
│       └── login.test.js     # 通常のテスト
└── playwright.config.js

⚡ 試験運用のポイント

  1. 環境変数での制御

    # 試験時のみMCPサーバー起動
NODE_ENV=test npx playwright test

  2. リソース節約設定

    // test-mcp.js
await startMcpServer({
  snapshotOnly: true, // ビジョンモード無効化
  maxConcurrency: 1   // 並列実行制限
});

  3. AI連携の最小化

    // mcp-utils.js
export const executeTestAction = async (action) => {
  if (process.env.NODE_ENV !== 'test') return;
  // テスト環境でのみMCPリクエスト送信
};

💡 推奨アプローチ

  1. ヘルパー関数の活用

    // tests/mcp/mcp-utils.js
export const mcpClick = async (selector) => {
  if (!process.env.MCP_URL) return;
  await fetch(`${process.env.MCP_URL}/click`, {
    method: 'POST',
    body: JSON.stringify({ selector })
  });
};

// テスト内で使用
await mcpClick('#submit-button');

  2. CI/CD連携（GitHub Actions例）

    - name: Run MCP Tests
  run: |
    npm run test:mcp
  env:
    NODE_ENV: test
    MCP_URL: http://localhost:2777

  3. モックの導入

    // 非試験環境ではダミー関数に差し替え
export const mcpClick = process.env.NODE_ENV === 'test' 
  ? realClick 
  : () => console.log('MCP operation skipped');

🔍 検証済みメリット

  • リソース削減：ビジョンモード無効化でCPU負荷50%減 [3:1]
  • 実行時間短縮：並列制限によりテスト安定性向上 [1:1]
  • 設定簡素化：環境変数切替で本番環境への影響ゼロ [2:1]

この構成により、試験時のみMCPを有効化しつつ、本番環境では完全に無視される安全な実装が可能です [1:2] [2:2] [3:2]。詳細はPlaywright MCPテストガイド参照。

脚注

  1. https://qiita.com/t-kurasawa/items/fc47a9133dd6cfe1ae7b ↩︎ ↩︎ ↩︎

  2. https://azure-ai-agent.hatenablog.com/entry/2025/03/28/Copilot-Playweight-MCP ↩︎ ↩︎ ↩︎

  3. https://t-cr.jp/article/m7f1iviehlbd3a0 ↩︎ ↩︎ ↩︎

Yasutaka NishiiYasutaka Nishii

Claude Code x Gemini CLI MCP

Yasutaka NishiiYasutaka Nishii

はい、その運用方針は非常に理にかなっています。

  • Webの確認
    Gemini CLIはGoogle検索やWebページ要約が非常に得意なので、最新の情報収集や外部サイトの要約、PRやIssueページの確認を自動化できます。直接URLを渡して「要約して」と頼むだけで、内容をすばやく把握できます [1]。

  • ファイル要約
    複数のドキュメントやコード、PR差分・リポジトリ全体なども、自然言語で「このディレクトリを要約して」など指示すれば、Gemini CLIが自動で解析・要点抽出を行います。全ファイルの再帰的な要約や、特定のファイル・ディレクトリ単位での要約も非常に高速・強力です [2] [1:1] [3]。

  • Claude Codeの成果物の第三者レビュー
    Claude Codeが生成したコードやドキュメントも、Gemini CLIに「このコードを第三者視点でレビューして」「改善点や疑問点を出して」などと依頼すれば、俯瞰的・批判的視点でフィードバックやレビューコメントを得られます [1:2] [3:1]。

Gemini CLIの特徴

  • ユーザーは複雑なコマンドやツールの知識は不要で、「こうしてほしい」と自然言語で指示を出すだけでOK [1:3]。
  • 検索・要約・レビューなど、煩雑なタスクを一括して処理できるため、作業効率や網羅性が格段に向上します [1:4] [3:2]。

運用例（イメージ）

  1. Webで調べたい内容やPRページのURLをGemini CLIに渡し、要約や解説を取得
  2. 対象ファイルやディレクトリの要約をGemini CLIに依頼
  3. Claude CodeによるアウトプットをGemini CLIで第三者レビュー

この流れなら、「情報収集→要約→レビュー」までAIでスムーズに一貫化できます。

「やりたいことを普段の言葉で指示するだけで、Geminiが最適なツールを自動で選択し、実行します。」 [1:5]

今の用途なら**Gemini CLIを“AIによるWeb/ファイル解析・第三者的フィードバック専用エージェント”**として活用し、Claude Codeはプロジェクト推進・生成に特化する棲み分けがおすすめです。

脚注

  1. https://zenn.dev/hashito/articles/0c7c382a5f8aee ↩︎ ↩︎ ↩︎ ↩︎ ↩︎ ↩︎

  2. https://forest.watch.impress.co.jp/docs/serial/aistream/2028156.html ↩︎

  3. https://note.com/873ch/n/nb845f0835b9e ↩︎ ↩︎ ↩︎

Yasutaka NishiiYasutaka Nishii

GitHubタグの全てのPRを読んでリリースノートを書くケースでの、Claude Code・Gemini CLI（MCP）・GitHubの機能の棲み分け方についてまとめます。

最適な棲み分け例

役割 担当（推奨） 内容
PR収集／分類 GitHub自動生成機能
（GitHub Release, Actions）		 対象タグやリリース範囲で結合されたPR一覧や、ラベルによる自動分類・差分抽出。公式の「自動生成リリースノート」でもPR/コミット単位にカテゴライズやリスト化が可能 [1] [2] [3] [4]。
PR本文・差分の要約 Gemini CLI（MCP） 各PRの本文やdiff内容、議論ポイント等をAIで簡潔に要約。機械的な一覧だけでは不十分な場合、Geminiで「要点抽出」や「一文まとめ」を生成（例：gemini run pr.mdやWeb要約）。
構造・見出し設計、ドラフト執筆 Claude Code 要約結果・全体像から「わかりやすいリリースノート」への再構成や編集。重要な変更やBreaking変更の抽出、ユーザー向けの語調調整など、高度な自然言語処理・編集。
最終チェック（第三者レビュー視点） Gemini CLI または Claude Code 完成ドラフトを別エージェントの視点で客観レビュー（誤り・漏れ・表現チェック）。

推奨フロー例

  1. GitHubの自動生成機能やAPI、Actionsで、対象タグ（リリース範囲）の全PRを一覧・抽出

    • 「リリース」画面やgh release create --generate-notesコマンド、Actionsによる自動収集が可能 [1:1] [2:1] [3:1] [4:1]。

  2. Gemini CLIでPRごとの要点抽出・要約

    • Web要約が得意なので、PR画面のURLやdiffファイルなどを与え「このPRのキモだけまとめて」と指示。
    • ラベルやタイトル、議論ポイントなども抽出可能。

  3. Claude Codeで全体構成とユーザー向け編集

    • Geminiの要約＋GitHubの自動分類をもとに、「リリースノートのドラフトをわかりやすく整形」や「重要な変更を冒頭で強調」「変更理由やインパクトについて加筆」など、自然言語による“わかりやすい編集”を担当。

  4. Gemini CLIまたはClaude Codeで第三者レビュー

    • 完成ドラフトを「客観的にレビュー」「誤りや過不足、表現の改善点」をチェック。

ポイント

  • 単純な一覧・分類はGitHubの自動生成やActionsで十分。
  • 要約や要点抽出はGemini CLIが大量・スピード・要約精度とも得意。
  • ユーザー目線の説明、物語性・インパクト重視の編集はClaude Codeに強み。
  • レビューはどちらでもよいが、第三者エージェント視点を意識。

こうすることで、手作業や一発生成では難しい「情報の網羅・分かりやすさ・品質チェック」をAIを組み合わせて実現できます。
必要に応じて全自動化も可能ですが、「AI×人の割り切り」や「最終編集だけ人間が担う」運用も有効です [1:2] [2:2] [3:2] [4:2]。

脚注

  1. https://docs.github.com/ja/repositories/releasing-projects-on-github/automatically-generated-release-notes ↩︎ ↩︎ ↩︎

  2. https://efcl.info/2023/03/11/auto-release-note/ ↩︎ ↩︎ ↩︎

  3. https://zenn.dev/rehabforjapan/articles/github-actions-release-note ↩︎ ↩︎ ↩︎

  4. https://kakakakakku.hatenablog.com/entry/2024/12/05/191940 ↩︎ ↩︎ ↩︎

Yasutaka NishiiYasutaka Nishii

Cluade Code x Gemini CLI のアクセス制限

サンドボックス

DevContaier - https://zenn.dev/mixi/articles/c2a11b1765b149
→ VSCode x DevContainer が安全と思われる

Yasutaka NishiiYasutaka Nishii

「AIがサンドボックス内でのみコマンド実行」とは、**Gemini CLIなどのAIがターミナルやOS上で直接コマンドを実行する際に、安全性を担保するために“外部と隔離された限定的な仮想環境（サンドボックス）だけでコマンドを動かす”**という意味です。

詳細

  • サンドボックスとは？
    サンドボックスは、“外部から隔離された安全な仮想環境”を指します。
    例えばDockerやPodmanなどのコンテナ、あるいは限定権限の仮想ディレクトリ・プロセスとしてAIがプログラムやシェルコマンドを実行します [1] [2] [3]。

  • なぜサンドボックスで実行するのか？
    AIが自由にローカルコマンドやファイル操作をしてしまうと、誤操作やセキュリティ上のリスクがあります。しかし、「サンドボックス内だけでAIが実行できる」設定にすると、

  • システムの重要ファイルや個人データへのアクセスを防止

  • もしAIが何か誤った命令を出しても“限定された安全な範囲”内に影響を封じ込められる
    といった効果が得られます [1:1] [2:1] [3:1]。

  • Gemini CLIの場合の運用例
    環境変数などで

export GEMINI_SANDBOX=true

を設定する、もしくは--sandbox-imageでDockerイメージを指定することで、AIのコマンド実行がサンドボックス環境（＝隔離コンテナや仮想領域）内のみに限定されます [1:2] [2:2] [3:2]。

「GEMINI_SANDBOX環境変数はツールの安全性を担保する最も重要な機能。コンテナ内でGemini CLI自身を再実行し、外部への影響を最小にする」 [1:3]

要約
「AIがサンドボックス内でのみコマンド実行」とは、AIによるコマンドやスクリプトの実行範囲を仮想的な安全領域内に限定し、システムや他ファイルへの不要なアクセス・破壊などリスクを防止するための仕組みです [1:4] [2:3] [3:3]。

脚注

  1. https://gist.github.com/mizchi/53fee8a015bb8f74a3e832bf92661fb5 ↩︎ ↩︎ ↩︎ ↩︎ ↩︎

  2. https://forest.watch.impress.co.jp/docs/serial/aistream/2028156.html ↩︎ ↩︎ ↩︎ ↩︎

  3. https://programmingforever.hatenablog.com/entry/2025/06/26/102209 ↩︎ ↩︎ ↩︎ ↩︎

Yasutaka NishiiYasutaka Nishii

はい、その理解で正しいです。**VSCodeのDevContainerは“Dockerコンテナと本質的に同等の隔離環境”**です。
つまり「DevContainer内でGemini CLI MCPサーバを動かす」ということは、**Docker上でGemini CLI MCPを動かすことと同じく、“コンテナという仮想環境の中だけがAIエージェントの実行・アクセス範囲”**になります [1] [2] [3]。

どうして同等なの？

  • DevContainer＝Dockerコンテナを使った開発環境そのもの
    VSCode Dev Containers拡張は、開発環境をDockerコンテナ内に構築する仕組みです。そのため「どこにアクセスできるか」「どんなコマンドやツールを動かせるか」は、そのコンテナの中に限定されます [1:1] [2:1] [3:1]。

  • ホストOSや他のフォルダとは物理的に分離
    DevContainerでマウントorクローンしたディレクトリのみがAIやツールから見えるようになり、外部（ホストPCや他のディレクトリ）への読み書きは不可です [2:2] [3:2]。

  • Docker上に構築した場合とセキュリティや挙動は同じ

「VS Code Dev Containers extension lets you use a Docker container as a full-featured development environment.」 [1:2]

「You can open any folder or repository inside a container」 [3:3]

まとめ
「DevContainer内でGemini CLI MCPを動かす」＝「Docker上で動かす」のと同じで、そのコンテナ内のファイル・コマンド・ネットワークだけがAIの有効範囲に限定され、安全性・隔離性もDockerと同等です [1:3] [2:3] [3:4]。

脚注

  1. https://code.visualstudio.com/docs/devcontainers/create-dev-container ↩︎ ↩︎ ↩︎ ↩︎

  2. https://docs.calitp.org/benefits/development/ ↩︎ ↩︎ ↩︎ ↩︎

  3. https://code.visualstudio.com/docs/devcontainers/containers ↩︎ ↩︎ ↩︎ ↩︎ ↩︎

Yasutaka NishiiYasutaka Nishii

Claude Code Tips

Yasutaka NishiiYasutaka Nishii

MCP メモ

  • 引数で実行場所決める

    • ここに dot env ファイル
    • 出力先
    • などを含められる

  • Mulmo

    • yarn build
    • build ファイルのフルパスを設定
{
  "mcpServers": {
        "mulmo": {
          "type": "stdio",
          "command": "node",
          "args": [
            "/Users/[USERNAME]/Documents/mac-workspace/mulmocast-cli/lib/mcp/server.js",
            "--base-dir",
            "/Users/[USERNAME]/Documents/mac-workspace/mulmocast-cli",
            "--output-dir",
            "/Users/[USERNAME]/Documents/mac-workspace/mulmocast-cli/output/",
            "--date-subdir"
          ],
          "env": {
          }
        }
}
Yasutaka NishiiYasutaka Nishii

変更前と変更後のコードを比較しました。主な変更点は以下の通りです：

主な変更点

1. dotenvの読み込み方法の変更 

// 変更前
import "dotenv/config";

// 変更後  
import dotenv from "dotenv";
// ...
dotenv.config({ path: path.join(baseDirPath, '.env') });

固定的な読み込みから、指定されたベースディレクトリから.envファイルを読み込むように変更。

2. コマンドライン引数の解析機能を追加 

// 変更後で追加された部分
const args = process.argv.slice(2);
let baseDirPath = process.cwd();
let outputDirPath: string | undefined;
let useDateSubdir = false;

// Parse named arguments
for (let i = 0; i < args.length; i++) {
  if (args[i] === '--base-dir' && args[i + 1]) {
    baseDirPath = args[i + 1];
    i++;
  } else if (args[i] === '--output-dir' && args[i + 1]) {
    outputDirPath = args[i + 1];
    i++;
  } else if (args[i] === '--date-subdir') {
    useDateSubdir = true;
  }
}

3. saveMulmoScriptToOutput関数の拡張 

// 変更前
const saveMulmoScriptToOutput = async (mulmoScript: MulmoScript): Promise<string>

// 変更後
const saveMulmoScriptToOutput = async (mulmoScript: MulmoScript): Promise<{ filePath: string; outputDir: string }>
  • 戻り値が文字列から{ filePath, outputDir }オブジェクトに変更
  • カスタム出力ディレクトリのサポート
  • 日付サブディレクトリ機能の追加（YYYYMMDD_HHMMSS形式）

4. argvオブジェクトの拡張 

// 変更前
const argv = {
  file: filePath,
  l: options.lang,
  // ...
};

// 変更後
const argv = {
  file: filePath,
  o: outputDir,  // 出力ディレクトリを追加
  l: options.lang,
  // ...
};

変更の意図

これらの変更により、MCPサーバーは：

  1. 柔軟な設定: 異なるプロジェクトディレクトリで動作可能
  2. カスタム出力: 出力先を自由に指定可能
  3. 整理された出力: 日付別のサブディレクトリで出力を整理
  4. 設定の分離: プロジェクトごとの.envファイルを使用

これにより、より実用的で柔軟なMCPサーバーになっています。