# Lagune

> あらゆるコードベースのための Security-Driven Hardening

Lagune は、オープンソースで防御専用の Security-Driven Hardening（SDH）ワークフローです。あらゆる言語のあらゆるコードベースを、どの段階でも AI エージェントが堅牢化できるよう支援します。charter は開発前にセキュリティのルールを定め、汎用の /lagune コマンドは書いているそばからコードを堅牢化し、5 フェーズの Blue Team フローはシステムが実際に何をしているかを検出して、そのコンテキストで重要な修正を進めます。コマンドは skills CLI でエージェントにインストールでき、API キーは不要です。

---

# インストール：どの AI エージェントでも使えるセキュリティ強化

> Lagune はどのプロジェクトにもインストールできます。エージェントが対応していればプラグインとして、それ以外では skills CLI で導入し、プロジェクトに合ったセキュリティの専門知識を選びます。

正規 URL: https://lagune.ai/ja-JP/docs
言語: ja-JP
原文: https://lagune.ai/docs
最終更新日: 2026-11-03

**Lagune** は、AI エージェントがプロジェクトをより安全にするのを手伝います。コードに対して実行すると、エージェントはシステムが実際に何をしているかを把握したうえで、そのシステムにとって重要なセキュリティ作業を順に案内します。**Lagune** は、[Security-Driven Hardening (SDH)](https://lagune.ai/ja-JP/docs/references/paper) という方法論の最初のプロジェクトです。

**OSS を応援**

**Lagune** が気に入りましたか？[**GitHub** で ⭐ をお願いします](https://github.com/wellwelwel/lagune)

## エージェントを選ぶ

- [Claude Code](https://lagune.ai/ja-JP/docs/install/claude-code): Anthropic のエージェント型コーディングツール
- [Codex](https://lagune.ai/ja-JP/docs/install/codex): OpenAI のコーディングエージェント
- [Cursor](https://lagune.ai/ja-JP/docs/install/cursor): AI コードエディター
- [GitHub Copilot](https://lagune.ai/ja-JP/docs/install/github-copilot-cli): GitHub の AI ペアプログラマー
- [Gemini CLI](https://lagune.ai/ja-JP/docs/install/gemini-cli): Google のオープンソースのターミナルエージェント
- [Antigravity](https://lagune.ai/ja-JP/docs/install/antigravity-cli): Google のエージェント型開発プラットフォーム
- [OpenCode](https://lagune.ai/ja-JP/docs/install/opencode): オープンソースのコーディングエージェント
- [Devin for Terminal](https://lagune.ai/ja-JP/docs/install/devin-cli): Cognition のターミナルエージェント
- [Factory Droid](https://lagune.ai/ja-JP/docs/install/factory-droid): Factory のソフトウェア開発エージェント
- [Grok Build](https://lagune.ai/ja-JP/docs/install/grok-build): xAI のコーディングエージェント
- [Qwen Code](https://lagune.ai/ja-JP/docs/install/qwen-code): Qwen のターミナル向けコーディングエージェント
- [Kimi Code](https://lagune.ai/ja-JP/docs/install/kimi-code): Moonshot AI のコーディングエージェント
- [Muse Code](https://lagune.ai/ja-JP/docs/install/muse-code): Meta のコーディングエージェント
- [Pi](https://lagune.ai/ja-JP/docs/install/pi): ミニマルなターミナル向けコーディングエージェント
- [Hermes Agent](https://lagune.ai/ja-JP/docs/install/hermes-agent): Nous Research のオープンソースエージェント
- [汎用](https://lagune.ai/ja-JP/docs/install/universal): Cline, Kiro CLI, Windsurf, Zed ほか 66 種類

**備考**

- **Lagune** は内部で **Node.js** を使って動作しますが、開発に使う言語は自由です。
- 完全にオフラインで実行するには、`npm i -D lagune@0.16.0` で **Lagune** をプロジェクトにインストールします。

## カテゴリ

**Lagune** のセキュリティに関する知見は [**専門知識**](https://lagune.ai/ja-JP/docs/catalog) という単位で提供され、[**カテゴリ**](https://lagune.ai/ja-JP/docs/categories) ごとにまとめられています。

- **OWASP** (`owasp`): OWASP が追跡するアプリケーションセキュリティのリスクに備えて堅牢化：インジェクション、アクセス制御の不備、認証や暗号化の失敗
- **インフラストラクチャ** (`infra`): コンテナー、ワークロード、サーバーレスの設定を堅牢化：Dockerfile、Compose、Pod セキュリティ、FaaS の IAM とトリガー
- **AI / LLM** (`ai`): AI・LLM との連携を堅牢化し、プロンプトインジェクションや、ツール・エージェント・検索・MCP の安全でない接続を防ぐ
- **Lovable** (`lovable`): AI が生成した Supabase アプリ（Lovable など）を堅牢化：RLS の不備、service_role キーの漏えい、安全でないデフォルト設定
- **JavaScript** (`javascript`): JavaScript とそのランタイムを堅牢化し、eval や child_process による RCE、パストラバーサル、プロトタイプ汚染を防ぐ
- **Python** (`python`): Python を堅牢化し、pickle や YAML のデシリアライズによる RCE、str.format による文字列トラバーサル、クラス汚染を防ぐ
- **Rust** (`rust`): Rust を堅牢化し、健全でない unsafe API、transmute の誤用、整数オーバーフロー、FFI 境界での未定義動作を防ぐ
- **Java** (`java`): Java を堅牢化し、ObjectInputStream のデシリアライズを悪用してリモートコード実行に至るガジェットチェーンを防ぐ
- **Ruby** (`ruby`): Ruby を堅牢化し、Marshal.load や YAML のデシリアライズを悪用してリモートコード実行に至るガジェットチェーンを防ぐ
- **PHP** (`php`): PHP を堅牢化し、型ジャグリングによる認証回避、オブジェクトインジェクションのガジェットチェーン、安全でないデフォルト設定を防ぐ
- **Go** (`go`): Go を堅牢化し、型付き nil インターフェースのバグ、goroutine のデータ競合、セキュリティ上重要な経路での安全でない並行処理を防ぐ
- **C / C++** (`c-cpp`): C と C++ を堅牢化し、コード実行につながる書式文字列のバグ、バッファオーバーフロー、境界外書き込みを防ぐ
- **.NET** (`dotnet`): .NET と C# を堅牢化し、BinaryFormatter のデシリアライズによる RCE や、XSS につながるエンコーダーの回避を防ぐ

選んだカテゴリのキーを付けて `npx lagune write add --categories` を実行してください。

**ヒント**

プロジェクトは `owasp` から始まり、[`/lagune-charter`](https://lagune.ai/ja-JP/docs/commands/charter) がプロジェクトを読み解いたうえで、その内容に裏付けられたカテゴリを追加します。

## 動作要件

システムに [**Node.js (LTS)**](https://nodejs.org/en/download/package-manager) がインストールされている必要があります。

## バッジを使う ✨

**Lagune** をお使いですか？**README** にバッジを追加しましょう：

**2 色**

![Secured By Lagune](https://img.shields.io/badge/Lagune-2f7bff?logo=springsecurity&logoColor=white&label=Secured%20By&labelColor=303952)

```md
[![Secured By Lagune](https://img.shields.io/badge/Lagune-2f7bff?logo=springsecurity&logoColor=white&label=Secured%20By&labelColor=303952)](https://lagune.ai)
```

![Security Powered By Lagune](https://img.shields.io/badge/Lagune-2f7bff?logo=springsecurity&logoColor=white&label=Security%20Powered%20By&labelColor=303952)

```md
[![Security Powered By Lagune](https://img.shields.io/badge/Lagune-2f7bff?logo=springsecurity&logoColor=white&label=Security%20Powered%20By&labelColor=303952)](https://lagune.ai)
```

![Security-Driven Hardening with Lagune](https://img.shields.io/badge/Lagune-2f7bff?logo=springsecurity&logoColor=white&label=Security-Driven%20Hardening&labelColor=303952)

```md
[![Security-Driven Hardening with Lagune](https://img.shields.io/badge/Lagune-2f7bff?logo=springsecurity&logoColor=white&label=Security-Driven%20Hardening&labelColor=303952)](https://lagune.ai)
```

**単色**

![Secured By Lagune](https://img.shields.io/badge/Secured%20By%20Lagune-2f7bff?logo=springsecurity&logoColor=white)

```md
[![Secured By Lagune](https://img.shields.io/badge/Secured%20By%20Lagune-2f7bff?logo=springsecurity&logoColor=white)](https://lagune.ai)
```

![Security Powered By Lagune](https://img.shields.io/badge/Security%20Powered%20By%20Lagune-2f7bff?logo=springsecurity&logoColor=white)

```md
[![Security Powered By Lagune](https://img.shields.io/badge/Security%20Powered%20By%20Lagune-2f7bff?logo=springsecurity&logoColor=white)](https://lagune.ai)
```

![Security-Driven Hardening](https://img.shields.io/badge/Security--Driven%20Hardening-2f7bff?logo=springsecurity&logoColor=white)

```md
[![Security-Driven Hardening](https://img.shields.io/badge/Security--Driven%20Hardening-2f7bff?logo=springsecurity&logoColor=white)](https://lagune.ai)
```

## 次のステップ

**Lagune** の各 [**スキル**](https://lagune.ai/ja-JP/docs/get-started/commands) の役割を確認しましょう。

## よくある質問

### Lagune とは何ですか？

Lagune は、AI エージェントがあらゆるコードベースを堅牢化するのを支援する、オープンソースで防御専用のセキュリティワークフローです。コードに対して実行すると、システムが実際に何をしているかを検出し、その状況にとって重要なセキュリティ修正を案内します。

### Lagune はどうやってインストールしますか？

エージェントを選んでください：Claude Code、GitHub Copilot CLI、Muse Code、Antigravity CLI、Cursor、Kimi Code、OpenCode、Codex CLI、Factory Droid、Grok Build、Devin CLI、Hermes Agent ではプラグインとして、Gemini CLI と Qwen Code では拡張機能として、Pi ではパッケージとして Lagune をインストールし、それ以外のエージェントでは npx skills add wellwelwel/lagune でインストールします。新規プロジェクトでも既存のプロジェクトでも使えます。

### Lagune に API キーは必要ですか？

いいえ。ご自身の AI エージェントを通じて動作するため、API キーは不要です。

### 動作要件は何ですか？

システムに Node.js (LTS) がインストールされている必要があります。

### Lagune はどのプログラミング言語に対応していますか？

どの言語にも対応しています。Lagune 自体は内部で Node.js を使って動作しますが、どのプログラミング言語で書かれたプロジェクトでも監査し、堅牢化できます。

### Lagune はプロジェクトに何を追加しますか？

プロジェクトのセキュリティ状態を保存する .lagune/ ディレクトリです。最初に書き込みを行うコマンドが作成します。さらに skills CLI はスラッシュコマンドをプロジェクト内にインストールし、エージェントはそこから読み込みますが、プラグインの場合はコマンドをエージェントの内部に保持します。

### Lagune はどうやって更新しますか？

インストールしたときと同じ方法で更新します。各エージェントのインストールページに、そのエージェントでの Lagune の更新方法が載っており、skills CLI の場合は npx skills update で更新します。セキュリティ原則、各フェーズの成果物、独自に追加した専門知識はそのまま残ります。

### プロジェクトではどの専門知識が使われますか？

プロジェクトのカテゴリに含まれる組み込みの専門知識と、プロジェクト独自の専門知識です。charter はプロジェクトを読み解いた結果に裏付けられたカテゴリを記録し、npx lagune write add --categories でそれらを変更できます。

### プロジェクトのセキュリティ対策は、開発が終わってからでないとできませんか？

いいえ。/lagune コマンドは、書いているそばから作業を堅牢化します。どんなプロンプトでも受け付けて、依頼されたものを構築し、セキュリティ原則に沿って安全なデフォルト設定で堅牢化します。既存のコードを監査するのは、5 フェーズの Blue Team フローです。

### Lagune で既存のプロジェクトを監査できますか？

はい。5 フェーズの Blue Team フローが既存のコードを監査します：charter がセキュリティルールを定め、detect がシステムの動作とリスクの所在を洗い出し、plan が各検出事項を評価して修正を対応づけ、harden が修正を適用し、verify が修正の有効性を証明してクローズします。

### Lagune を使うのと、エージェントに脆弱性やセキュリティ上の欠陥を洗い出すよう頼むだけなのとでは、何が違いますか？

エージェントが単独でコードを読むと、脆弱性らしく見えるものは見つけますが、対策らしく見えるものは素通りします。ブロック対象のアドレス一覧があると、すでに誰かがリスクに対処したように見えるため、その一覧が大半のアドレスを取りこぼしていることを誰も確かめないまま、コードがリリースされます。Lagune はこの前提をひっくり返します：コードにすでにある防御処理は確認するまで未証明とみなし、カタログ内のすべての専門知識に明確な判定を下し、verify は対策があるかどうかではなく、リスクがなくなったかどうかを問います。また、各検出事項は実行をまたいでも 1 つの追跡項目のままなので、リスクが解消されたことを証明してクローズできます。一方、ただ頼むだけでは毎回違うレポートが返ってくるため、比べようがありません。

### Lagune を使って開発するのと、エージェントに安全なコードを書くよう頼むだけなのとでは、何が違いますか？

安全なコードを頼むだけでは、何をもって安全とするかをエージェントに委ねることになり、しかも何を頼めばよいかを分かっていることが前提になります。必要な要件は、たいてい依頼した本人もエージェントも気づかないまま、すでに依頼の中に含まれています：ユーザーがアクセスできる講座を表示するページを頼めば、それだけで認可のルールを示していることになり、書かれなかったチェックは、コード上に気づく手がかりを何も残しません。/lagune コマンドは、最初の 1 行を書く前に、セキュリティ原則と、これから構築するものに合う専門知識を読み込み、そのうえで、使った防御に照らして結果を読み直します。安全な書き方が安全でない書き方よりコストがかかることはめったにないので、結果を左右するのはどちらを選ぶべきかを知っているかどうかであり、それこそが最初の段階で手に入るものです。

### Lagune は DAST（動的アプリケーションセキュリティテスト）を実行したり、稼働中のアプリケーションをテストしたりしますか？

いいえ。Lagune はコードを読むだけで、システムを実行したり、細工したリクエストを送ったりすることはありません。verify が確認するのは、対策がソースコードに存在し、正しく実装されているかどうかです。これは稼働中の環境で攻撃を受けても対策が持ちこたえるかどうかとは別の問いなので、"cannot tell from the code"（コードからは判断できない）は、黙って合格扱いにするのではなく、正当な判定のひとつです。DAST は実行時の問いに、Lagune はソースコードの問いに答えるため、どちらかがもう一方の代わりになることはありません。オプションの prove コマンドでさえこの一線を守っています：そのテストが検証するのは安全な振る舞いであり、攻撃ペイロードではありません。

### Lagune はペネトレーションテスト（ペンテスト）の代わりになりますか？

いいえ、決して代わりにはなりません！ペネトレーションテストは、正式な承認のもとで専門家が稼働中のシステムに対して自らの判断で進める作業で、複数の検出事項を連鎖させたり、攻撃対象領域ごとのルールでは表しきれないビジネスロジックを探ったりします。ペネトレーションテストの検出事項は、detect で懸念事項として扱うことで Lagune の Blue Team フローに取り込めるので、専門家が報告した内容も計画、堅牢化、検証まで進められます。

## セキュリティポリシー

[SECURITY.md](https://github.com/wellwelwel/lagune/blob/main/SECURITY.md) をご確認ください。

## ライセンス

**Lagune** は [Apache License 2.0](https://github.com/wellwelwel/lagune/blob/main/LICENSE) のもとで提供されています。

Copyright © 2026-present [Weslley Araújo](https://github.com/wellwelwel) および [コントリビューター](https://github.com/wellwelwel/lagune/graphs/contributors)。

---

# Antigravity CLI に Lagune をプラグインとしてインストール

> Antigravity CLI に Lagune をプラグインとしてインストールし、最新の状態に保ち、エンジンの実行を事前に許可します。

正規 URL: https://lagune.ai/ja-JP/docs/install/antigravity-cli
言語: ja-JP
原文: https://lagune.ai/docs/install/antigravity-cli
最終更新日: 2026-11-03

ターミナルからプラグインをインストールします：

```bash
agy plugin install https://github.com/wellwelwel/lagune/tree/plugin-antigravity
```

## 更新

**Lagune** を更新するには、もう一度インストールします：

```bash
agy plugin install https://github.com/wellwelwel/lagune/tree/plugin-antigravity
```

## コマンド

コマンドはプラグイン名を付けて入力します。たとえば `/lagune:lagune-charter` で `/lagune-charter` を実行します。

---

**権限**

エンジンは 2 つのツールで動作します。`lagune_read` はプロジェクトを読み取るだけで、`lagune_write` は `.lagune/` に書き込むだけです。セッションの最初のメッセージとして送ったコマンドは、これらのツールが読み込まれる前に実行されるため、代わりに **npx** を使います。ツールと **npx** を事前に許可するには、`~/.gemini/antigravity-cli/settings.json` に次のルールを追加します：

```json
{
  "permissions": {
    "allow": [
      "mcp(lagune_lagune/lagune_read)",
      "mcp(lagune_lagune/lagune_write)",
      "command(regex:npx --yes lagune@[0-9.]+)"
    ]
  }
}
```

## よくある質問

### Antigravity CLI に Lagune をインストールするにはどうすればよいですか？

agy plugin install https://github.com/wellwelwel/lagune/tree/plugin-antigravity を実行します。

### Antigravity CLI で Lagune を更新するにはどうすればよいですか？

agy plugin install https://github.com/wellwelwel/lagune/tree/plugin-antigravity をもう一度実行します。

### Antigravity CLI で Lagune のコマンドを実行するにはどうすればよいですか？

/lagune:lagune-charter のように、プラグイン名を付けて入力します。

### Antigravity CLI で、許可を求められずに Lagune を実行できますか？

はい。Antigravity CLI の設定で mcp(lagune_lagune/lagune_read)、mcp(lagune_lagune/lagune_write)、command(regex:npx --yes lagune@[0-9.]+) を許可します。npx のルールは、セッションの最初のメッセージとして送ったコマンドに適用されます。

---

# Claude Code に Lagune をプラグインとしてインストール

> Claude Code のターミナル、拡張機能、デスクトップアプリに Lagune をプラグインとしてインストールし、最新の状態に保ち、エンジンの実行を事前に許可します。

正規 URL: https://lagune.ai/ja-JP/docs/install/claude-code
言語: ja-JP
原文: https://lagune.ai/docs/install/claude-code
最終更新日: 2026-11-03

**ターミナル**

ターミナルからプラグインをインストールします：

```bash
claude plugin install lagune --marketplace wellwelwel/lagune
```

**Claude Code** のセッションからもインストールできます：

```text
/plugin marketplace add wellwelwel/lagune
/plugin install lagune@lagune
```

**拡張機能**

- `/plugin` と入力し、**Manage plugins** を選択します。
- **Marketplaces** タブで `wellwelwel/lagune` を追加します。
- **Plugins** タブで `lagune` をインストールします。

**デスクトップ**

- ターミナルか拡張機能から **Lagune** をインストールします。拡張機能では **Install for you** を選びます。
- デスクトップアプリで新しいセッションを開始すると、自分用にインストールしたプラグインが読み込まれます。

## 更新

**ターミナル**

**Lagune** を更新するには、次のコマンドを実行します：

```bash
claude plugin marketplace update lagune
claude plugin update lagune@lagune
```

常に最新の状態に保つには、`lagune` マーケットプレイスの **Enable auto-update** を `/plugin` から選択します。

**拡張機能**

- `/plugin` と入力し、**Manage plugins** を選択します。
- **Marketplaces** タブを開きます。
- `lagune` の更新アイコンを選択します。

**デスクトップ**

- ターミナルか拡張機能から **Lagune** を更新します。
- デスクトップアプリで新しいセッションを開始します。

## コマンド

`/lagune-charter` のようにコマンド名をそのまま入力するか、`/lagune:lagune-charter` のようにプラグイン名を付けて入力します。

---

**権限**

エンジンは 2 つのツールで動作します。`lagune_read` はプロジェクトを読み取るだけで、`lagune_write` は `.lagune/` に書き込むだけです。これらを事前に許可するには、次のルールを、1 つのプロジェクトなら `.claude/settings.json` に、すべてのプロジェクトなら `~/.claude/settings.json` に追加します：

```json
{
  "permissions": {
    "allow": [
      "mcp__plugin_lagune_lagune__lagune_read",
      "mcp__plugin_lagune_lagune__lagune_write"
    ]
  }
}
```

**skills.sh** でインストールした場合など、エンジンが **npx** 経由で動作するときは、`Bash(npx --yes lagune@*)` を許可します。サンドボックスを有効にしている場合は、`registry.npmjs.org` も `sandbox.network.allowedDomains` に追加します。

## よくある質問

### Claude Code に Lagune をインストールするにはどうすればよいですか？

claude plugin install lagune --marketplace wellwelwel/lagune を実行します。セッションや拡張機能では、プラグインマネージャーから wellwelwel/lagune マーケットプレイスを追加し、lagune をインストールします。ターミナルか拡張機能で自分用にインストールすれば、デスクトップアプリでも読み込まれます。

### Claude Code で Lagune を更新するにはどうすればよいですか？

claude plugin marketplace update lagune を実行してから claude plugin update lagune@lagune を実行するか、lagune マーケットプレイスの Enable auto-update を /plugin から選択します。拡張機能では、/plugin から Manage plugins を開き、lagune マーケットプレイスの更新アイコンを選択します。デスクトップアプリは、次のセッションで更新を読み込みます。

### Claude Code で Lagune のコマンドを実行するにはどうすればよいですか？

/lagune-charter のようにコマンド名をそのまま入力するか、/lagune:lagune-charter のようにプラグイン名を付けて入力します。

### Claude Code で、許可を求められずに Lagune を実行できますか？

はい。Claude Code の設定で mcp__plugin_lagune_lagune__lagune_read と mcp__plugin_lagune_lagune__lagune_write を許可します。エンジンが npx 経由で動作する場合は、Bash(npx --yes lagune@*) も許可します。

---

# Codex CLI に Lagune をプラグインとしてインストール

> Codex CLI に Lagune をプラグインとしてインストールし、最新の状態に保ち、サンドボックス内でエンジンを実行します。

正規 URL: https://lagune.ai/ja-JP/docs/install/codex
言語: ja-JP
原文: https://lagune.ai/docs/install/codex
最終更新日: 2026-11-03

ターミナルからプラグインをインストールします：

```bash
codex plugin marketplace add wellwelwel/lagune
codex plugin add lagune@lagune
```

## 更新

**Lagune** を更新するには、次のコマンドを実行します：

```bash
codex plugin marketplace upgrade lagune
```

## コマンド

`$` に続けてプラグイン名付きのコマンドを入力し、そのあとに入力内容を書きます。たとえば `$lagune:lagune-charter` で `/lagune-charter` を実行します。`$` と入力するとコマンドの一覧が表示され、選ぶと完全な名前が挿入されます。

---

**権限**

**Codex** のサンドボックスはネットワークにアクセスできません。自分のターミナルからプロジェクトにエンジンをインストールします。最初に一度、その後は更新のたびに実行してください：

```bash
npm i -D lagune@0.16.0
```

## よくある質問

### Codex CLI に Lagune をインストールするにはどうすればよいですか？

codex plugin marketplace add wellwelwel/lagune を実行してから、codex plugin add lagune@lagune を実行します。

### Codex CLI で Lagune を更新するにはどうすればよいですか？

codex plugin marketplace upgrade lagune を実行します。

### Codex CLI で Lagune のコマンドを実行するにはどうすればよいですか？

$lagune:lagune-charter のように、$ に続けてプラグイン名付きのコマンドを入力し、そのあとに入力内容を書きます。

### Codex のサンドボックス内で Lagune は動作しますか？

はい。自分のターミナルから npm i -D lagune@0.16.0 を実行してプロジェクトにエンジンをインストールすれば動作します。最初に一度、その後は更新のたびに実行してください。

---

# Cursor に Lagune をプラグインとしてインストール

> Cursor と Cursor CLI に Lagune をプラグインとしてインストールし、最新の状態に保ち、エンジンの実行を事前に許可します。

正規 URL: https://lagune.ai/ja-JP/docs/install/cursor
言語: ja-JP
原文: https://lagune.ai/docs/install/cursor
最終更新日: 2026-11-03

**Cursor**

- **Customize** を開きます。
- **From GitHub Repository** を選択し、`https://github.com/wellwelwel/lagune` を入力します。
- **Lagune** の **Install** を選択し、プロジェクトかユーザーのスコープを選びます。

**Cursor CLI**

- ターミナルからマーケットプレイスを追加します：

  ```bash
  agent plugin marketplace add https://github.com/wellwelwel/lagune --git-ref plugin-cursor
  ```

- `/plugins` を `agent` のセッションで入力します。
- **Lagune** をインストールします。

**Claude Code** に **Lagune** をインストール済みなら、**Cursor CLI** はそこから読み込みます。

## 更新

**Cursor**

- **Customize** を開きます。
- `lagune` マーケットプレイスの **Refresh** を選択します。

**Cursor CLI**

- ターミナルからマーケットプレイスを置き換えます：

  ```bash
  agent plugin marketplace remove lagune
  agent plugin marketplace add https://github.com/wellwelwel/lagune --git-ref plugin-cursor
  ```

- `/plugins` を `agent` のセッションで入力します。
- **Lagune** をもう一度インストールします。

## コマンド

`/lagune-charter` のように、コマンド名をそのまま入力します。

---

**権限**

**Cursor** では、コマンドが **npx** 経由でエンジンを実行します。デフォルトの Auto-review モードなら、確認なしで許可されます。

**Cursor CLI** では、エンジンは 2 つのツールで動作します。`lagune_read` はプロジェクトを読み取るだけで、`lagune_write` は `.lagune/` に書き込むだけです。これらを事前に許可するには、次のルールを、1 つのプロジェクトなら `.cursor/cli.json` に、すべてのプロジェクトなら `~/.cursor/cli-config.json` に追加します：

```json
{
  "permissions": {
    "allow": [
      "Mcp(plugin-lagune-lagune:lagune_read)",
      "Mcp(plugin-lagune-lagune:lagune_write)"
    ]
  }
}
```

**skills.sh** でインストールした場合など、エンジンが **npx** 経由で動作するときは、`Shell(npx:--yes lagune@*)` を許可します。

## よくある質問

### Cursor に Lagune をインストールするにはどうすればよいですか？

Cursor では、Customize を開いて From GitHub Repository を選択し、https://github.com/wellwelwel/lagune を入力して Lagune をインストールします。Cursor CLI では、agent plugin marketplace add https://github.com/wellwelwel/lagune --git-ref plugin-cursor を実行してから、/plugins で Lagune をインストールします。

### Cursor で Lagune を更新するにはどうすればよいですか？

Cursor では、Customize で lagune マーケットプレイスの Refresh を選択します。Cursor CLI では、lagune マーケットプレイスを削除して追加し直し、/plugins で Lagune をもう一度インストールします。

### Cursor で Lagune のコマンドを実行するにはどうすればよいですか？

/lagune-charter のように、コマンド名をそのまま入力します。

### Cursor で、許可を求められずに Lagune を実行できますか？

はい。Cursor のデフォルトの Auto-review モードでは、すでに許可されています。Cursor CLI では、Mcp(plugin-lagune-lagune:lagune_read) と Mcp(plugin-lagune-lagune:lagune_write) を許可します。エンジンが npx 経由で動作する場合は、Shell(npx:--yes lagune@*) も許可します。

---

# Devin CLI に Lagune をプラグインとしてインストール

> Devin CLI に Lagune をプラグインとしてインストールし、最新の状態に保ちます。

正規 URL: https://lagune.ai/ja-JP/docs/install/devin-cli
言語: ja-JP
原文: https://lagune.ai/docs/install/devin-cli
最終更新日: 2026-11-03

**Devin** にサインインしてから、ターミナルからプラグインをインストールします：

```bash
devin auth login
devin plugins install wellwelwel/lagune
```

## 更新

**Lagune** を更新するには、次のコマンドを実行します：

```bash
devin plugins update lagune
```

## コマンド

コマンドはプラグイン名を付けて入力します。たとえば `/lagune:lagune-charter` で `/lagune-charter` を実行します。`/` メニューにも表示されます。

## よくある質問

### Devin CLI に Lagune をインストールするにはどうすればよいですか？

devin auth login でサインインしてから、devin plugins install wellwelwel/lagune を実行します。

### Devin CLI で Lagune を更新するにはどうすればよいですか？

devin plugins update lagune を実行します。

### Devin CLI で Lagune のコマンドを実行するにはどうすればよいですか？

/lagune:lagune-charter のように、プラグイン名を付けて入力します。/ メニューにも表示されます。

---

# Factory Droid に Lagune をプラグインとしてインストール

> Factory Droid に Lagune をプラグインとしてインストールし、最新の状態に保ち、エンジンのツールを許可します。

正規 URL: https://lagune.ai/ja-JP/docs/install/factory-droid
言語: ja-JP
原文: https://lagune.ai/docs/install/factory-droid
最終更新日: 2026-11-03

ターミナルからプラグインをインストールします：

```bash
droid plugin marketplace add wellwelwel/lagune
droid plugin install lagune@lagune
```

## 更新

**Lagune** を更新するには、次のコマンドを実行します：

```bash
droid plugin marketplace update lagune
droid plugin update lagune@lagune
```

## コマンド

`/lagune-charter` のように、コマンド名をそのまま入力します。

---

**権限**

エンジンは 2 つのツールで動作します。`lagune_read` はプロジェクトを読み取るだけで、`lagune_write` は `.lagune/` に書き込むだけです。**Factory Droid** が確認を求めてきたら、それぞれを常に許可するよう選びます。`lagune` マーケットプレイスの新しいコミットを同期すると、もう一度確認を求めてきます。この同期は起動時に行われることがあります。

## よくある質問

### Factory Droid に Lagune をインストールするにはどうすればよいですか？

droid plugin marketplace add wellwelwel/lagune を実行してから、droid plugin install lagune@lagune を実行します。

### Factory Droid で Lagune を更新するにはどうすればよいですか？

droid plugin marketplace update lagune を実行してから、droid plugin update lagune@lagune を実行します。

### Factory Droid で Lagune のコマンドを実行するにはどうすればよいですか？

/lagune-charter のように、コマンド名をそのまま入力します。

### Factory Droid で、許可を求められずに Lagune を実行できますか？

はい。Factory Droid が確認を求めてきたら、lagune_read と lagune_write を常に許可するよう選びます。lagune マーケットプレイスの新しいコミットを同期すると、もう一度確認を求めてきます。

---

# Gemini CLI に Lagune を拡張機能としてインストール

> Gemini CLI に Lagune を拡張機能としてインストールし、最新の状態に保ち、エンジンの実行を事前に許可します。

正規 URL: https://lagune.ai/ja-JP/docs/install/gemini-cli
言語: ja-JP
原文: https://lagune.ai/docs/install/gemini-cli
最終更新日: 2026-11-03

ターミナルから拡張機能をインストールします：

```bash
gemini extensions install https://github.com/wellwelwel/lagune
```

## 更新

**Lagune** を更新するには、次のコマンドを実行します：

```bash
gemini extensions update lagune
```

常に最新の状態に保つには、`--auto-update` を付けてインストールします。

## コマンド

コマンドは拡張機能名を付けて入力します。たとえば `/lagune:lagune-charter` で `/lagune-charter` を実行します。

---

**権限**

エンジンは 2 つのツールで動作します。`lagune_read` はプロジェクトを読み取るだけで、`lagune_write` は `.lagune/` に書き込むだけです。**Gemini CLI** は、信頼済みフォルダーでのみこれらを起動します。これらを事前に許可するには、次のルールを `~/.gemini/policies/lagune.toml` として保存します：

```toml
[[rule]]
mcpName = "lagune"
toolName = ["lagune_read", "lagune_write"]
decision = "allow"
priority = 100
```

**skills.sh** でインストールした場合など、エンジンが **npx** 経由で動作するときは、同じファイルに次のルールを追加します：

```toml
[[rule]]
toolName = "run_shell_command"
commandRegex = 'npx --yes lagune@\d+\.\d+\.\d+\s'
decision = "allow"
priority = 100
```

## よくある質問

### Gemini CLI に Lagune をインストールするにはどうすればよいですか？

gemini extensions install https://github.com/wellwelwel/lagune を実行します。

### Gemini CLI で Lagune を更新するにはどうすればよいですか？

gemini extensions update lagune を実行するか、--auto-update を付けて拡張機能をインストールします。

### Gemini CLI で Lagune のコマンドを実行するにはどうすればよいですか？

/lagune:lagune-charter のように、拡張機能名を付けて入力します。

### Gemini CLI で、許可を求められずに Lagune を実行できますか？

はい。lagune サーバーの lagune_read と lagune_write ツールを許可するポリシールールを追加します。エンジンが npx 経由で動作する場合は、npx --yes lagune@ のあとにバージョンが続くコマンドを許可する run_shell_command のルールも追加します。

---

# GitHub Copilot CLI に Lagune をプラグインとしてインストール

> GitHub Copilot CLI に Lagune をプラグインとしてインストールし、最新の状態に保ちます。

正規 URL: https://lagune.ai/ja-JP/docs/install/github-copilot-cli
言語: ja-JP
原文: https://lagune.ai/docs/install/github-copilot-cli
最終更新日: 2026-11-03

ターミナルからプラグインをインストールします：

```bash
copilot plugin marketplace add wellwelwel/lagune
copilot plugin install lagune@lagune
```

エディターでは、[**skills.sh**](https://lagune.ai/ja-JP/docs/install/universal) を使って **GitHub Copilot** 用に **Lagune** をインストールします。

## 更新

**Lagune** を更新するには、次のコマンドを実行します：

```bash
copilot plugin marketplace update lagune
copilot plugin update lagune@lagune
```

## コマンド

`/lagune-charter` のように、コマンド名をそのまま入力します。

## よくある質問

### GitHub Copilot CLI に Lagune をインストールするにはどうすればよいですか？

copilot plugin marketplace add wellwelwel/lagune を実行してから、copilot plugin install lagune@lagune を実行します。

### GitHub Copilot CLI で Lagune を更新するにはどうすればよいですか？

copilot plugin marketplace update lagune を実行してから、copilot plugin update lagune@lagune を実行します。

### GitHub Copilot CLI で Lagune のコマンドを実行するにはどうすればよいですか？

/lagune-charter のように、コマンド名をそのまま入力します。

### VS Code の GitHub Copilot で Lagune を使えますか？

はい。VS Code などのエディターでは、プラグインではなく skills.sh で Lagune をインストールします。

---

# Grok Build に Lagune をプラグインとしてインストール

> Grok Build に Lagune をプラグインとしてインストールし、最新の状態に保ち、エンジンの実行を事前に許可します。

正規 URL: https://lagune.ai/ja-JP/docs/install/grok-build
言語: ja-JP
原文: https://lagune.ai/docs/install/grok-build
最終更新日: 2026-11-03

ターミナルからプラグインをインストールします：

```bash
grok plugin install wellwelwel/lagune@plugin-grok --trust
```

## 更新

**Lagune** を更新するには、次のコマンドを実行します：

```bash
grok plugin update lagune
```

## コマンド

`/lagune-charter` のようにコマンド名をそのまま入力するか、`/lagune:lagune-charter` のようにプラグイン名を付けて入力します。

---

**権限**

エンジンは 2 つのツールで動作します。`lagune_read` はプロジェクトを読み取るだけで、`lagune_write` は `.lagune/` に書き込むだけです。これらを事前に許可するには、`~/.grok/config.toml` に次のルールを追加します：

```toml
[permission]
allow = ["MCPTool(lagune__lagune_read)", "MCPTool(lagune__lagune_write)"]
```

**skills.sh** でインストールした場合など、エンジンが **npx** 経由で動作するときは、`Bash(npx --yes lagune@*)` を許可します。

## よくある質問

### Grok Build に Lagune をインストールするにはどうすればよいですか？

grok plugin install wellwelwel/lagune@plugin-grok --trust を実行します。

### Grok Build で Lagune を更新するにはどうすればよいですか？

grok plugin update lagune を実行します。

### Grok Build で Lagune のコマンドを実行するにはどうすればよいですか？

/lagune-charter のようにコマンド名をそのまま入力するか、/lagune:lagune-charter のようにプラグイン名を付けて入力します。

### Grok Build で、許可を求められずに Lagune を実行できますか？

はい。Grok Build の設定で MCPTool(lagune__lagune_read) と MCPTool(lagune__lagune_write) を許可します。エンジンが npx 経由で動作する場合は、Bash(npx --yes lagune@*) も許可します。

---

# Hermes Agent に Lagune をプラグインとしてインストール

> Hermes Agent に Lagune をプラグインとしてインストールし、最新の状態に保ちます。

正規 URL: https://lagune.ai/ja-JP/docs/install/hermes-agent
言語: ja-JP
原文: https://lagune.ai/docs/install/hermes-agent
最終更新日: 2026-11-03

ターミナルからプラグインをインストールします：

```bash
hermes plugins install wellwelwel/lagune --enable
```

- **Hermes Agent** がカタログ外のプラグインについて確認を求めてきたら、**承認します**。
- リポジトリの **Node.js** 依存関係をインストールするか尋ねてきたら、**拒否します**。

## 更新

**Lagune** を更新するには、次のコマンドを実行します：

```bash
hermes plugins update lagune
```

## コマンド

コマンドはプラグイン名を付けて入力します。たとえば `/lagune:lagune-charter` で `/lagune-charter` を、`/lagune:lagune` で `/lagune` を実行します。

## よくある質問

### Hermes Agent に Lagune をインストールするにはどうすればよいですか？

hermes plugins install wellwelwel/lagune --enable を実行します。確認を求められたらプラグインを承認し、リポジトリの Node.js 依存関係のインストールは拒否します。

### Hermes Agent で Lagune を更新するにはどうすればよいですか？

hermes plugins update lagune を実行します。

### Hermes Agent で Lagune のコマンドを実行するにはどうすればよいですか？

/lagune:lagune-charter や /lagune:lagune のように、プラグイン名を付けて入力します。

---

# Kimi Code に Lagune をプラグインとしてインストール

> Kimi Code に Lagune をプラグインとしてインストールし、最新の状態に保ちます。

正規 URL: https://lagune.ai/ja-JP/docs/install/kimi-code
言語: ja-JP
原文: https://lagune.ai/docs/install/kimi-code
最終更新日: 2026-11-03

**Kimi Code** のセッションからプラグインをインストールし、**Trust and install** を選んでから、新しいセッションを開始して読み込みます：

```text
/plugins install https://github.com/wellwelwel/lagune
/new
```

## 更新

**Lagune** を更新するには、もう一度インストールします：

```text
/plugins install https://github.com/wellwelwel/lagune
/new
```

## コマンド

コマンドはプラグイン名を付けて入力します。たとえば `/lagune:lagune-charter` で `/lagune-charter` を実行します。`/` メニューには `/skill:lagune:lagune-charter` の形で表示され、この形でも実行できます。

## よくある質問

### Kimi Code に Lagune をインストールするにはどうすればよいですか？

Kimi Code のセッションで /plugins install https://github.com/wellwelwel/lagune を実行し、Trust and install を選んでから /new を実行します。

### Kimi Code で Lagune を更新するにはどうすればよいですか？

/plugins install https://github.com/wellwelwel/lagune をもう一度実行してから、/new を実行します。

### Kimi Code で Lagune のコマンドを実行するにはどうすればよいですか？

/lagune:lagune-charter のようにプラグイン名を付けて入力するか、/skill:lagune:lagune-charter のように / メニューに表示される形で入力します。

---

# Muse Code に Lagune をプラグインとしてインストール

> Muse Code に Lagune をプラグインとしてインストールし、最新の状態に保ち、サンドボックス内でエンジンを実行します。

正規 URL: https://lagune.ai/ja-JP/docs/install/muse-code
言語: ja-JP
原文: https://lagune.ai/docs/install/muse-code
最終更新日: 2026-11-03

ターミナルからプラグインをインストールします：

```bash
muse plugins marketplace add lagune wellwelwel/lagune
muse plugins install lagune@lagune
```

## 更新

**Lagune** を更新するには、マーケットプレイスを更新してからプラグインを再インストールします：

```bash
muse plugins marketplace update lagune
muse plugins remove lagune
muse plugins install lagune@lagune
```

## コマンド

`/lagune-charter` のようにコマンド名をそのまま入力するか、`/lagune:lagune-charter` のようにプラグイン名を付けて入力します。

---

**権限**

**Muse Code** のサンドボックスはエンジンをダウンロードできません。自分のターミナルからプロジェクトにエンジンをインストールします。最初に一度、その後は更新のたびに実行してください：

```bash
npm i -D lagune@0.16.0
```

## よくある質問

### Muse Code に Lagune をインストールするにはどうすればよいですか？

muse plugins marketplace add lagune wellwelwel/lagune を実行してから、muse plugins install lagune@lagune を実行します。

### Muse Code で Lagune を更新するにはどうすればよいですか？

muse plugins marketplace update lagune を実行してから、muse plugins remove lagune と muse plugins install lagune@lagune で再インストールします。

### Muse Code で Lagune のコマンドを実行するにはどうすればよいですか？

/lagune-charter のようにコマンド名をそのまま入力するか、/lagune:lagune-charter のようにプラグイン名を付けて入力します。

### Muse Code のサンドボックス内で Lagune は動作しますか？

はい。自分のターミナルから npm i -D lagune@0.16.0 を実行してプロジェクトにエンジンをインストールすれば動作します。最初に一度、その後は更新のたびに実行してください。

---

# OpenCode に Lagune をプラグインとしてインストール

> OpenCode 1.x と 2.x に Lagune をプラグインとしてインストールし、最新の状態に保ちます。

正規 URL: https://lagune.ai/ja-JP/docs/install/opencode
言語: ja-JP
原文: https://lagune.ai/docs/install/opencode
最終更新日: 2026-11-03

**OpenCode 2.x**

ターミナルからプラグインをインストールします：

```bash
opencode plugin add lagune
```

または、`plugins` リスト（`opencode.json` 内）に追加します：

```json
{
  "plugins": ["lagune"]
}
```

**OpenCode 1.x**

ターミナルからプロジェクトにプラグインをインストールします。すべてのプロジェクトにインストールするには `-g` を付けます：

```bash
opencode plugin lagune
```

または、`plugin` リスト（`opencode.json` 内）に追加します：

```json
{
  "plugin": ["lagune"]
}
```

## 更新

**OpenCode 2.x**

**Lagune** を更新するには、次のコマンドを実行します：

```bash
opencode plugin update lagune
opencode reload
```

**OpenCode 1.x**

**Lagune** を更新するには、新しいリリースを上書きインストールします。すべてのプロジェクトにインストールした場合は `-g` を付けます：

```bash
opencode plugin lagune@0.16.0 --force
```

## コマンド

**OpenCode 2.x**

`@` と入力して `@lagune-charter` などのコマンドを選び、同じメッセージに続けて入力内容を書きます。

**OpenCode 1.x**

`/lagune-charter` のように、コマンド名をそのまま入力します。コマンドは `/skills` に一覧表示され、`/` メニューには表示されません。

---

**権限**

エンジンは 2 つのツールで動作します。`lagune_read` はプロジェクトを読み取るだけで、`lagune_write` は `.lagune/` に書き込むだけです。**OpenCode** は確認なしでこれらを実行します。

## よくある質問

### OpenCode に Lagune をインストールするにはどうすればよいですか？

OpenCode 2.x では、opencode plugin add lagune を実行します。OpenCode 1.x では、opencode plugin lagune を実行します。すべてのプロジェクトにインストールするには -g を付けます。

### OpenCode で Lagune を更新するにはどうすればよいですか？

OpenCode 2.x では、opencode plugin update lagune を実行してから opencode reload を実行します。OpenCode 1.x では、opencode plugin lagune@0.16.0 --force を実行します。

### OpenCode で Lagune のコマンドを実行するにはどうすればよいですか？

OpenCode 2.x では、@ と入力して @lagune-charter などのコマンドを選び、同じメッセージに続けて入力内容を書きます。OpenCode 1.x では、/lagune-charter のようにコマンド名をそのまま入力するか、/skills から探します。

### OpenCode は Lagune の実行前に許可を求めますか？

いいえ。OpenCode は、エンジンの 2 つのツールである lagune_read と lagune_write を確認なしで実行します。

---

# Pi に Lagune をパッケージとしてインストール

> npm または GitHub から、Pi に Lagune をパッケージとしてインストールし、最新の状態に保ちます。

正規 URL: https://lagune.ai/ja-JP/docs/install/pi
言語: ja-JP
原文: https://lagune.ai/docs/install/pi
最終更新日: 2026-11-03

**npm**

ターミナルからパッケージをインストールします：

```bash
pi install npm:lagune
```

**GitHub**

**GitHub** から最新のコミットをインストールします。この場合、エンジンは **npx** 経由で動作します：

```bash
pi install git:github.com/wellwelwel/lagune
```

## 更新

**npm**

**Lagune** を更新するには、次のコマンドを実行します：

```bash
pi update npm:lagune
```

**GitHub**

**Lagune** を更新するには、次のコマンドを実行します：

```bash
pi update git:github.com/wellwelwel/lagune
```

`pi update --extensions` はインストールしたすべてのパッケージを更新します。`pi update` だけでは **Pi** しか更新されません。

## コマンド

コマンドは `skill:` プレフィックスを付けて入力します。たとえば `/skill:lagune-charter` で `/lagune-charter` を実行します。

## よくある質問

### Pi に Lagune をインストールするにはどうすればよいですか？

pi install npm:lagune を実行します。GitHub の最新コミットをインストールするなら、pi install git:github.com/wellwelwel/lagune を実行します。

### Pi で Lagune を更新するにはどうすればよいですか？

pi update npm:lagune を実行します。GitHub からインストールした場合は、pi update git:github.com/wellwelwel/lagune を実行します。pi update --extensions は、インストールしたすべてのパッケージを更新します。

### Pi で Lagune のコマンドを実行するにはどうすればよいですか？

/skill:lagune-charter のように、skill: プレフィックスを付けて入力します。

---

# Qwen Code に Lagune を拡張機能としてインストール

> Qwen Code に Lagune を拡張機能としてインストールし、最新の状態に保ち、エンジンの実行を事前に許可します。

正規 URL: https://lagune.ai/ja-JP/docs/install/qwen-code
言語: ja-JP
原文: https://lagune.ai/docs/install/qwen-code
最終更新日: 2026-11-03

ターミナルから拡張機能をインストールします：

```bash
qwen extensions install lagune
```

## 更新

**Lagune** を更新するには、次のコマンドを実行します：

```bash
qwen extensions update lagune
```

常に最新の状態に保つには、`--auto-update` を付けてインストールします。

## コマンド

コマンドは拡張機能名を付けて入力します。たとえば `/lagune:lagune-charter` で `/lagune-charter` を実行します。

---

**権限**

エンジンは 2 つのツールで動作します。`lagune_read` はプロジェクトを読み取るだけで、`lagune_write` は `.lagune/` に書き込むだけです。これらを事前に許可するには、次のルールを、1 つのプロジェクトなら `.qwen/settings.json` に、すべてのプロジェクトなら `~/.qwen/settings.json` に追加します：

```json
{
  "permissions": {
    "allow": ["mcp__lagune__lagune_read", "mcp__lagune__lagune_write"]
  }
}
```

**skills.sh** でインストールした場合など、エンジンが **npx** 経由で動作するときは、`Shell(npx --yes lagune@*)` を許可します。

## よくある質問

### Qwen Code に Lagune をインストールするにはどうすればよいですか？

qwen extensions install lagune を実行します。

### Qwen Code で Lagune を更新するにはどうすればよいですか？

qwen extensions update lagune を実行するか、--auto-update を付けて拡張機能をインストールします。

### Qwen Code で Lagune のコマンドを実行するにはどうすればよいですか？

/lagune:lagune-charter のように、拡張機能名を付けて入力します。

### Qwen Code で、許可を求められずに Lagune を実行できますか？

はい。Qwen Code の設定で mcp__lagune__lagune_read と mcp__lagune__lagune_write を許可します。エンジンが npx 経由で動作する場合は、Shell(npx --yes lagune@*) も許可します。

---

# skills.sh であらゆるエージェントに Lagune をインストール

> skills CLI で、あらゆる AI エージェントに Lagune をインストールし、最新の状態に保ちます。

正規 URL: https://lagune.ai/ja-JP/docs/install/universal
言語: ja-JP
原文: https://lagune.ai/docs/install/universal
最終更新日: 2026-11-03

**ターミナル**

[**skills.sh**](https://www.skills.sh/wellwelwel/lagune) を使って、ターミナルから **Lagune** のコマンドをインストールします：

```bash
npx skills add wellwelwel/lagune
```

**プロンプト**

次のプロンプトをエージェントに貼り付けます：

```md
`npx --yes skills add wellwelwel/lagune` を実行し、生成されたスキルの指示に今すぐ従ってください。出力全体を読んでください。必要なら、先に一時ファイルへリダイレクトしてください。相対パスは、出力に示されたサポートファイルのディレクトリを基準に解決してください。
```

## 更新

**ターミナル**

**Lagune** を更新するには、次のコマンドを実行します：

```bash
npx skills update
```

**プロンプト**

**Lagune** を更新するには、次のプロンプトをエージェントに貼り付けます：

```md
`npx --yes skills update -y` を実行し、出力全体を読んでください。必要なら、先に一時ファイルへリダイレクトしてください。
```

---

**インストール方法はエージェントごとにひとつ**

**Lagune** は **skills.sh** か**プラグイン**のどちらか一方でインストールし、両方を併用しないでください。

**権限**

コマンドは `npx --yes lagune@0.16.0` でエンジンを実行します。これを事前に許可するルールは、各 [エージェントのインストールページ](https://lagune.ai/ja-JP/docs) に記載しています。ネットワークにアクセスできないサンドボックスでは、自分のターミナルからプロジェクトにエンジンをインストールします。最初に一度、その後は更新のたびに実行してください：

```bash
npm i -D lagune@0.16.0
```

## よくある質問

### あらゆる AI エージェントに Lagune をインストールするにはどうすればよいですか？

プロジェクトで npx skills add wellwelwel/lagune を実行するか、インストール用のプロンプトをエージェントに貼り付けます。

### skills CLI でインストールした Lagune を更新するにはどうすればよいですか？

npx skills update を実行するか、更新用のプロンプトをエージェントに貼り付けます。

### skills CLI とプラグインの両方で Lagune をインストールできますか？

いいえ。両方でインストールすると、エージェントがすべてのコマンドを重複して表示するか、片方だけを使ってもう片方を隠してしまいます。

---

# AI エージェントのためのセキュリティスキル

> Lagune で AI エージェントが使えるようになるスキル：既存のプロジェクトを監査することも、開発しながら新しいコードを安全にすることもでき、どちらもセキュリティ原則に従います。

正規 URL: https://lagune.ai/ja-JP/docs/get-started/commands
言語: ja-JP
原文: https://lagune.ai/docs/get-started/commands
最終更新日: 2026-11-03

**Lagune** を [インストール](https://lagune.ai/ja-JP/docs) すると、**AI** エージェントで一連のスキルが使えるようになります。使い方は 2 通りあり、どちらも**セキュリティ原則**に従います：開発しながら新しいコードを安全にするか、プロジェクト全体を監査するかです。

**⌨️ 構築 / 開発**

作業を終えてからセキュリティ対策をする必要はありません。**いま**書いているコードには [**`/lagune`**](https://lagune.ai/ja-JP/docs/commands/lagune) を使いましょう：

| スキル                                        | できること                                                           |
| --------------------------------------------- | -------------------------------------------------------------------- |
| [**/lagune-charter**](https://lagune.ai/ja-JP/docs/commands/charter) | プロジェクトのセキュリティルールを定め、`/lagune` が構築の土台にする |
| [**/lagune**](https://lagune.ai/ja-JP/docs/commands/lagune)          | 依頼されたものを構築し、セキュリティ原則に沿って書きながら堅牢化する |

**いつでも使える**

[**`/lagune`**](https://lagune.ai/ja-JP/docs/commands/lagune) は、実行するたびにセキュリティ原則で定めたルールを守ります。どんなプロンプトでも受け付け、依頼されたものを構築し、後からではなく作業を進めながら、安全なデフォルト設定で堅牢化します。

---

#### 特別なスキル

| スキル                                              | 役割                                                                                   |
| --------------------------------------------------- | -------------------------------------------------------------------------------------- |
| [**/lagune-specialize**](https://lagune.ai/ja-JP/docs/commands/specialize) | 記事、エクスプロイト、トピックから、新しいセキュリティの専門知識を **Lagune** に教える |

**🔬 監査：Blue Team フロー**

**Blue Team フロー**の全体像です：プロジェクトが何をしているかを読み取り、リスクを洗い出して解消します。各ステップは前のステップを土台にしているので、一覧を上から順に実行するだけで済みます：

| #   | スキル                                        | できること                                                             |
| --- | --------------------------------------------- | ---------------------------------------------------------------------- |
| 1   | [**/lagune-charter**](https://lagune.ai/ja-JP/docs/commands/charter) | プロジェクトのセキュリティルールを、提案に任せるか要望に沿って定める   |
| 2   | [**/lagune-detect**](https://lagune.ai/ja-JP/docs/commands/detect)   | コードを読み、システムが何をしているか、リスクがどこにあるかを洗い出す |
| 3   | [**/lagune-plan**](https://lagune.ai/ja-JP/docs/commands/plan)       | detect が見つけたものを防御計画にまとめ、検出事項ごとに修正を用意する  |
| 4   | [**/lagune-harden**](https://lagune.ai/ja-JP/docs/commands/harden)   | 計画の修正を、安全に 1 つずつコードへ適用する                          |
| 5   | [**/lagune-verify**](https://lagune.ai/ja-JP/docs/commands/verify)   | 適用した各修正が実際に有効かを証明し、有効だった検出事項をクローズする |

---

#### 特別なスキル

| スキル                                              | 役割                                                                                   |
| --------------------------------------------------- | -------------------------------------------------------------------------------------- |
| [**/lagune-specialize**](https://lagune.ai/ja-JP/docs/commands/specialize) | 記事、エクスプロイト、トピックから、新しいセキュリティの専門知識を **Lagune** に教える |
| [**/lagune-prove**](https://lagune.ai/ja-JP/docs/commands/prove)           | 各検出事項を、責任ある開示に使える、実行可能で防御専用の証明に変える                   |

---

#### 内部スキル

| スキル                                      | 役割                                  |
| ------------------------------------------- | ------------------------------------- |
| [**/lagune-repair**](https://lagune.ai/ja-JP/docs/commands/repair) | **Lagune** の内部の追跡情報を修復する |

**ヒント**

セキュリティはコストではなく投資です：最初にかけた手間は、起こらずに済んだインシデントの分だけ何倍にもなって返ってきます 🙋🏻‍♂️

## よくある質問

### Lagune にはどんなスキルがありますか？

開発しながら作業を堅牢化する /lagune と、5 フェーズの Blue Team 監査フロー（/lagune-charter、/lagune-detect、/lagune-plan、/lagune-harden、/lagune-verify）です。さらに /lagune-specialize と /lagune-prove もあります。

### Lagune の Blue Team フローとは何ですか？

5 つのフェーズからなる監査です：charter（ルールを定める）、detect（リスクを洗い出す）、plan（評価して修正を計画する）、harden（修正を適用する）、verify（修正が有効かを証明してクローズする）。

### /lagune と監査フローの違いは何ですか？

/lagune は、決まったフローに従うことなく、新しいコードを書きながら安全にします。監査フローは、既存のプロジェクトに対して 5 つのフェーズを順番に実行します。

---

# ダッシュボード

> コマンド 1 つで開くローカルのライブビューで、プロジェクトのセキュリティ原則、検出事項、カタログを確認できます。

正規 URL: https://lagune.ai/ja-JP/docs/get-started/dashboard
言語: ja-JP
原文: https://lagune.ai/docs/get-started/dashboard
最終更新日: 2026-11-03

サブコマンドを付けずに **Lagune** を直接実行すると、`.lagune/` をインタラクティブなライブビューで確認できます。ランダムなポートでダッシュボードを起動して開きます：

```bash
npx lagune
```

- [x] **ライブリロード**
- [x] **プライベート**かつ**ローカル**
- [x] 最初の charter から、`.lagune/` の内容をすべて表示
- [x] ブラウザから直接プロジェクトのカテゴリを**管理**できる
- [x] `node_modules` も `package.json` も不要 📦

![Lagune ダッシュボードのセキュリティ原則画面](https://lagune.ai/img/dashboard/02.webp)

![Lagune ダッシュボードの検出事項画面](https://lagune.ai/img/dashboard/03.webp)

![Lagune ダッシュボードの Side Quests 画面](https://lagune.ai/img/dashboard/04.webp)

![Lagune ダッシュボードの検出事項の詳細画面](https://lagune.ai/img/dashboard/05.webp)

![Lagune ダッシュボードのカタログ画面](https://lagune.ai/img/dashboard/06.webp)

**ヒント**

- 🚪 任意のポートを指定するには `--port` を使います。
- ⏏️ 停止するには `Ctrl+C` を押します。

## よくある質問

### Lagune のダッシュボードはどうやって開きますか？

プロジェクトのルートで、サブコマンドを付けずに npx lagune を実行します。ランダムなポートで .lagune/ のライブビューを起動し、ブラウザで開きます。

### ダッシュボードはプライベートですか？

はい。自分のマシン上だけで動作し、ほかのコンピューターからはアクセスできないローカルアドレスを使います。

### ダッシュボードからプロジェクトを変更できますか？

ブラウザから変更できるのはカテゴリだけです。それ以外にダッシュボードに表示される内容は、すべて読み取り専用です。

---

# /lagune: AI が書くそばからコードを安全に

> 依頼したものを構築し、セキュリティ原則に沿って書きながら堅牢化します。決まったフローに従う必要はありません。

正規 URL: https://lagune.ai/ja-JP/docs/commands/lagune
言語: ja-JP
原文: https://lagune.ai/docs/commands/lagune
最終更新日: 2026-11-03

⌨️ 依頼した作業を、書くそばから安全な形で仕上げます。**`/lagune`** はどの段階でもどんなプロンプトでも受け付け、求められたものを構築し、引き渡す前に安全なデフォルト設定で堅牢化します。

## 使い方

どんなプロンプトにも **`/lagune`** を付けて、いつもどおりに作業内容を説明します。

**📘 エージェント向けの指示**

```md
# エージェント向けのプロジェクト指示

<!-- ... -->

## セキュリティ

- コードを作成または変更するときは、必ず `/lagune` スキルを使い、デフォルトで安全性が高まるようにしてください。
```

    - 例：**AGENTS.md**、**CLAUDE.md**、**.github/copilot-instructions.md**、**.cursorrules** など。

**💬 新機能**

```prompt
/lagune ユーザーがプロフィールに自分の写真をアップロードできるようにしてください。
```

**💬 修正**

```prompt
/lagune ユーザーがフォームを送信しても何も起きません。原因を調べて修正してください。
```

**💬 リファクタリング**

```prompt
/lagune ペイロード処理のロジックを疎結合にして改善してください
```

**セキュリティ原則は任意だが、あるとより効果的**

**`/lagune`** はセキュリティ原則があってもなくても動作します。セキュリティ原則があれば、プロジェクト独自のルールがすべての構築に反映されます。[`/lagune-charter`](https://lagune.ai/ja-JP/docs/commands/charter) で一度定めておけば十分です。

## 仕組み

Lagune には何も書き込まずに、次の 3 つのステップで作業を進めます：

1. セキュリティ原則があれば読み込んで構築全体をその原則に従わせ、まだない場合はデフォルトで安全なベースラインを代わりに使います。
2. プロジェクトの [カタログ](https://lagune.ai/ja-JP/docs/catalog) の一覧を取得し、作業に関わる専門知識だけを、監査フローと同じようにオンデマンドで読み込みます。
3. コードを書きながら防御を施し、作業を引き渡す前に自分の成果を読み直して、対策が実際に有効かを確認します。

その結果、プロジェクトには最初の 1 行から安全な、動作するコードが残ります。

**いつでも使える**

detect も plan も、後片付けも不要です。**`/lagune`** は作ったばかりのひな形にも、成熟したコードベースへの変更にも同じように使え、後からではなく作業を進めながら堅牢化します。

## しないこと

- `.lagune` ディレクトリには成果物も追跡情報も一切書き込まないため、生み出すのは依頼した堅牢化済みのコードだけです。
- プロンプトに応えるためにルールを緩めることはないため、依頼内容がセキュリティ原則に反する場合は、そのまま安全でない形で構築せず、まず手を止めて知らせます。

## よくある質問

### /lagune は何をしますか？

どの段階でもどんなプロンプトでも受け付け、依頼されたものを構築し、引き渡す前に安全なデフォルト設定で堅牢化します。防御は後からではなく、コードを書きながら施します。

### /lagune を使うにはセキュリティ原則が必要ですか？

いいえ。セキュリティ原則があってもなくても動作します。セキュリティ原則があれば、プロジェクト独自のルールがすべての構築に反映されます。なければ、デフォルトで安全なベースラインを使います。

### /lagune と Blue Team フローの違いは何ですか？

/lagune は、決まったフローに従うことなく、新しいコードを書きながら安全にします。Blue Team フローは、既存のプロジェクトに対して 5 つの監査フェーズを順番に実行します。

### /lagune は検出事項を追跡したり、成果物を書き込んだりしますか？

いいえ。.lagune ディレクトリには成果物も追跡情報も一切書き込みません。生み出すのは、依頼した堅牢化済みのコードだけです。

### エージェントに /lagune を自動で使わせるにはどうすればよいですか？

エージェントの指示ファイル（AGENTS.md、CLAUDE.md、.cursorrules など）に、コードを作成または変更するときは必ず /lagune スキルを使うよう指示を追加します。

---

# /lagune-charter: セキュリティ原則を定める

> 後続のすべてのフェーズが守るルールとして、プロジェクトのセキュリティ原則を定め、プロジェクトを読み取って裏付けが得られた専門知識のカテゴリを記録します。

正規 URL: https://lagune.ai/ja-JP/docs/commands/charter
言語: ja-JP
原文: https://lagune.ai/docs/commands/charter
最終更新日: 2026-11-03

🧬 プロジェクトがどんなものかを **Lagune** に伝えると、それをセキュリティのルールに落とし込みます（説明がなくても、プロジェクトそのものからルールを導き出します）。

charter は全体を統括するレイヤーで、後続のすべてのフェーズが守らなければならない、セキュリティ優先の原則をまとめたものです。プロジェクトのセキュリティ態勢に対するコンパイル時チェックだと考えてください。

## 実行方法

**説明する**

```prompt
/lagune-charter このプロジェクトは、ゲームソフトを販売するオンラインストアです。顧客は商品をカートに入れ、クレジットカードか銀行振込で支払います。自分の注文と、それぞれの注文の状況を確認できます。
```

**Lagune に提案させる**

```prompt
/lagune-charter
```

> _決済ライブラリ、ログインの仕組み、顧客に紐づいた注文モデルがあります。何かを販売するオンラインストアのようです。顧客は支払いをして、自分の注文を追跡します_…… ☁️

## 導き出す内容

**Lagune** は説明や **PRD** を方向性として受け取り、それがセキュリティ面で何を意味するかを導き出したうえで、プロジェクトを読み取って、説明に含まれていない点まで掘り下げます。たとえば：

- カートが注文を保持しているということは、**データベース**があるということです。
  - 例：`"データはどこに保存されているか？"`、`"誰がアクセスできるか？"`、`"漏えいしていないか？"`。
- 顧客が自分の注文を確認できるということは、何らかの**ログインやアクセス制御**があるということです。
  - 例：`"ある顧客が別の顧客の注文にアクセスできないか？"`、`"セッションは保護されているか？"`。
- カードと銀行振込での支払いを受け付けるということは、**お金と機密データが関わる**ということです。
  - 例：`"カード情報は保存されているか？"`、`"支払いは検証されているか？"`。

説明とプロジェクトは互いに補い合います。説明が意図を定め、依存関係や README、設定を読み取ることで、説明に含まれていなかった点が浮かび上がります。それでも重要な点がはっきりしない場合、**Lagune** は推測せず、短くわかりやすい質問をします。

そこから **Lagune** は、プロジェクトに合わせたセキュリティルールを組み立てます。ルールは必要なときにいつでも見直し、調整できます。

**活用のヒント**

- プロジェクト独自のセキュリティルールを定義することもできます。
- 関連する情報を詳しく伝えるほど、最終的なレポートの質が上がります：
  - プロジェクトの概要、仕組み、内部で何が起きているかを説明してください。
  - エンドユーザーは誰ですか？ユーザーにできることと、できないことは何ですか？
  - 振る舞いに関する情報は、技術的な情報と同じくらい価値があります。
- charter の記録は `.lagune/memory/charter.md` にあります。

## 記録するカテゴリ

専門知識は後続のフェーズが必要なときだけ読み込むセキュリティの知識で、プロジェクトの [カタログ](https://lagune.ai/ja-JP/docs/catalog) には [カテゴリ](https://lagune.ai/ja-JP/docs/categories) 単位で加わります。プロジェクトにまだカテゴリが記録されていない間は、charter がプロジェクトを読み取って裏付けが得られたカテゴリ（プロジェクトの言語、LLM の呼び出し、コンテナーなど）をそれぞれ記録し、要約でその名前を示します。

カテゴリが記録されたあとは、charter はそれらに手を加えず、プロジェクトでまだ使っていないカテゴリの名前を挙げるだけです。カテゴリはいつでも自分で変更できます：

```bash
npx lagune write add --categories python
npx lagune write remove --categories python
```

## 次のステップ

ルールが決まったら、システムが実際に何をしているかを洗い出しましょう：[`/lagune-detect`](https://lagune.ai/ja-JP/docs/commands/detect)。

## よくある質問

### Lagune の charter とは何ですか？

charter は Lagune の全体を統括するレイヤーで、後続のすべてのフェーズが守らなければならない、セキュリティ優先の原則をまとめたものです。プロジェクトのセキュリティ態勢に対するコンパイル時チェックだと考えてください。

### charter はどこに保存されますか？

.lagune/memory/charter.md に保存されます。

### charter のルールを自分で書くことはできますか？

はい。Lagune は説明とコードをもとにルールを提案します。そのルールは書き換えも削除もでき、新しく追加したり、適用範囲を絞り込んだりもできます。

### charter は専門知識のカテゴリを決めてくれますか？

カテゴリがまだ記録されていない間だけです。その場合は、プロジェクトを読み取って裏付けが得られたカテゴリ（使用している言語や LLM の呼び出しなど）をそれぞれ記録します。一度カテゴリが記録されたあとは、それを変更することはありません。

---

# /lagune-detect: システムとそのリスクを洗い出す

> コードを読み取り、システムが何をしているのか、どこにリスクがあるのかを洗い出します。

正規 URL: https://lagune.ai/ja-JP/docs/commands/detect
言語: ja-JP
原文: https://lagune.ai/docs/commands/detect
最終更新日: 2026-11-03

🔬 システムが実際に何をしているのか、どこにリスクがあるのかを突き止めます。

detect はコードを読み取り、実際に見つけたものだけを、後続のフェーズが必要とする根拠とともに記録します。根幹となる指針は、創作ではなく検出です。

## 実行方法

**フルスキャン**

```prompt
/lagune-detect
```

**パスを指定**

```prompt
/lagune-detect src/routes/ src/auth.ts
```

**懸念を伝える**

```prompt
/lagune-detect 顧客データが外部に漏れることがないか確認してください
```

## 洗い出す内容

**Lagune** はコードを読み取り、見つけたものを洗い出します。各検出事項には、それが何か、なぜ重要か、そしてその根拠が含まれます。たとえば：

- **ファイルのアップロード**：システムがユーザーからファイルを受け付けています。
  - _重要な理由_：画像を装ったファイルに、悪意のあるコードが隠されているおそれがあります。
  - _根拠_：`POST /upload` のハンドラーが、ファイルの実際の種類を確認せず、クライアントが送ってきた MIME タイプをそのまま信用しています。
- **ログインとセッション**：ユーザーはサインインして自分のアカウントにアクセスします。
  - _重要な理由_：セッションの扱いが甘いと、アカウントが他人に乗っ取られるおそれがあります。
  - _根拠_：セッションを発行するロジックで、有効期限を設定しないままセッションが発行されています。

その過程で、detect はプロジェクトの [カタログ](https://lagune.ai/ja-JP/docs/catalog) にあるすべての専門知識をコードと照らし合わせて判定し、前提となるコンテキストがコードに存在するものを適用して、**Applied specializations** の下に記録します。harden と verify は、このリストを再利用します。

こうして、システムが何をしていて、どこにリスクがあるのかを示す明確なマップが手に入り、次のステップですぐに対処できます。

**ヒント**

- 再実行するとマップが更新され、解決済みの検出事項は外れ、新しい検出事項が加わります。
- detect のマップは `.lagune/memory/detect.md` にあります。

## 次のステップ

マップを計画に変えましょう：[`/lagune-plan`](https://lagune.ai/ja-JP/docs/commands/plan)。

## よくある質問

### /lagune-detect は何をしますか？

コードを読み取り、システムが何をしているのか、どこにリスクがあるのかを洗い出し、実際に見つけたものだけを記録します。指針は、創作ではなく検出です。

### Lagune の検出事項とは何ですか？

検出事項とは、検出されたリスク 1 件分のことで、それが何か、なぜ重要か、コード上の根拠を含みます。plan、harden、verify が引き継いでいく、追跡の単位です。

### detect のマップはどこに保存されますか？

.lagune/memory/detect.md に保存されます。

### detect はどの専門知識を使いますか？

プロジェクトのカタログにあるすべての専門知識が、コードと照らし合わせて判定されます。detect は前提となるコンテキストが存在するものを適用し、Applied specializations の下に記録します。

---

# /lagune-plan: 検出事項をスコアリングして修正を計画する

> detect が見つけたものを防御計画に変え、各検出事項をカテゴリと CVSS v4.0 スコアで評価して、それぞれに修正を割り当てます。

正規 URL: https://lagune.ai/ja-JP/docs/commands/plan
言語: ja-JP
原文: https://lagune.ai/docs/commands/plan
最終更新日: 2026-11-03

🛡️ detect が見つけたものを防御計画に変えます：各検出事項をカテゴリと CVSS v4.0 スコアで評価し、適用する修正を割り当てます。

## 実行方法

**すべてを計画**

```prompt
/lagune-plan
```

**パスを指定**

```prompt
/lagune-plan src/routes/upload.ts
```

**気になる点に絞る**

```prompt
/lagune-plan 機密データが漏れるおそれのある箇所
```

## 仕組み

このフェーズは detect の続きです。システムが何をしていて、それぞれにどんなリスクがあるかは detect がすでに見つけているため、plan はリスクを繰り返し述べるのではなく、その深刻さを評価し、どう対処するかを決めます。plan はコードを一切読まないため、どの修正も必ず detect が実際に検出したものを対象にすることになります。評価は CVSS v4.0 の方法に沿って行い、各検出事項にカテゴリ、CVSS v4.0 ベクトル（detect と charter が捉えた内容から導き出し、[`cvss` フック](https://lagune.ai/ja-JP/docs/hooks/cvss) でスコアを算出したもの）、そのスコアが該当する優先度の区分を付けます。各修正には、それが守る charter の原則も記されます。

たとえば：

- **ファイルのアップロード**（優先度：**緊急**）
  - _カテゴリ_：ファイルの無制限アップロード（CWE-434）。
  - _CVSS_：CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:H/VI:H/VA:H/SC:N/SI:N/SA:N（9.3、緊急）。
  - _この優先度の理由_：誰でもインターネット経由でアップロード機能にアクセスでき、しかも顧客のファイルを保存するサーバー上にあります。
  - _守る原則_：III. すべての入力は、検証されるまで信頼しない。
  - _修正_：ファイルの実際の種類とサイズを確認し、保存時に名前を変更し、アップロードされたファイルはコードとして実行できない場所に保存します。

こうして、評価と優先順位付けが済んだ修正のリストが手に入ります。各修正は検出事項に紐づいており、次のフェーズですぐに適用できます。スコアは推定ではなく、必ず計算で求めます。ベクトルにはプロジェクトの露出度と影響の大きさが Environmental メトリクスとして含まれているため、誰でも FIRST や NVD の計算ツールに貼り付けて、同じスコアを導き出せます。

**ヒント**

- detect の結果だけを土台にしています。detect で洗い出していないファイルや懸念がある場合は、先にそれを対象に `/lagune-detect` を実行するよう案内します。
- 再実行すると計画が更新され、完了した修正は外れ、新しい修正が加わります。
- 防御計画は `.lagune/memory/plan.md` にあります。

**detect に依存**

plan は [`/lagune-detect`](https://lagune.ai/ja-JP/docs/commands/detect) がすでに洗い出した内容だけをもとに動くため、先に detect を実行してください。

## 次のステップ

計画を適用しましょう：[`/lagune-harden`](https://lagune.ai/ja-JP/docs/commands/harden)。

## よくある質問

### Lagune は脆弱性の優先順位をどう決めますか？

/lagune-plan が、各検出事項をカテゴリと、cvss フックが算出した CVSS v4.0 スコアで評価し、適用する修正を割り当てます。

### Lagune は CVSS v4.0 を使っていますか？

はい。各検出事項に CVSS v4.0 のベクトルとスコアが付きます。スコアは cvss フックが FIRST の計算ツールと同じ計算式で算出するため、誰でもそこにベクトルを貼り付けて、スコアを再計算できます。

### plan はコードを読みますか？

いいえ。plan はコードを一切読まないため、どの修正も必ず detect が実際に検出したものを対象にすることになります。

---

# /lagune-harden: コードにセキュリティ修正を適用する

> 計画の修正を、安全に 1 つずつコードへ適用します。

正規 URL: https://lagune.ai/ja-JP/docs/commands/harden
言語: ja-JP
原文: https://lagune.ai/docs/commands/harden
最終更新日: 2026-11-03

🔧 計画の修正を、安全に 1 つずつコードへ適用します。

## 実行方法

**すべて適用**

```prompt
/lagune-harden
```

**パスを指定**

```prompt
/lagune-harden src/routes/upload.ts
```

**優先度で指定**

```prompt
/lagune-harden 緊急と重要
```

## 仕組み

各修正は計画の段階ですでに決まっているので、harden はそれを適用するだけです。コードに手を加える唯一のフェーズなので、慎重に進めます：すべての変更をレビューしやすく保つために修正は 1 つずつ適用し、修正を当てはめるために対策を弱めることも決してありません。たとえば、アップロードの修正は次のようになります：

- **ファイルのアップロード**（ステータス：**Applied**）
  - _変更内容_：ファイルの実際の種類とサイズを確認し、想定外のものはすべて拒否し、保存時に名前を変更し、コードとして実行できない場所に保存します。
  - _変更箇所_：`handleUpload` 関数と、そこから呼び出しているストレージのヘルパーです。

修正を完全に適用できない場合、harden は安全にできる範囲だけを実施し、残りを **Partial** または **Blocked** としてマークして、未解決のまま残します。

**Applied は検証済みではない**

Applied は、まだ証明されたという意味ではありません。それを証明するのが [verify](https://lagune.ai/ja-JP/docs/commands/verify) の役割です。

**ヒント**

- 計画の結果だけを土台にしています。計画にない修正やファイルがある場合は、先にそれを対象に `/lagune-plan` を実行するよう案内します。
- 再実行すると記録を現状と照合して更新し、元に戻された変更は外れ、新たに適用した修正が加わります。
- 堅牢化の記録は `.lagune/memory/harden.md` にあります。

**plan に依存し、コードを変更する**

harden は [`/lagune-plan`](https://lagune.ai/ja-JP/docs/commands/plan) を土台にしています。コードを変更する唯一のフェーズです。

## 次のステップ

各修正が有効であることを証明しましょう：[`/lagune-verify`](https://lagune.ai/ja-JP/docs/commands/verify)。

## よくある質問

### /lagune-harden はコードを変更しますか？

はい。コードに手を加える唯一のフェーズで、計画の修正を 1 つずつ適用します。

### Applied、Partial、Blocked はどういう意味ですか？

Lagune が各修正について記録するステータスです。Applied は修正が完了したこと、Partial は一部だけ完了したこと、Blocked は適用できなかったことを意味します。Applied は、まだ証明されたという意味ではありません。

### Lagune は確認なしで修正を適用しますか？

編集に承認が必要かどうかを決めるのは Lagune ではなく、使っているエージェントと、それを実行する権限モードです。Lagune 自体は独自の確認ステップを追加しません。それでも、修正を通すために対策を弱めることは決してなく、修正が charter のルールと衝突する場合は、作業を止めて先に知らせます。

---

# /lagune-verify: セキュリティ対策の有効性を証明する

> 適用した修正が実際に有効かを証明し、有効だった検出事項をクローズします。

正規 URL: https://lagune.ai/ja-JP/docs/commands/verify
言語: ja-JP
原文: https://lagune.ai/docs/commands/verify
最終更新日: 2026-11-03

⚖️ コードを読み、harden が記録した内容と突き合わせることで、適用した修正が実際に有効かを証明し、有効だった検出事項をクローズします。

## 実行方法

**すべて検証**

```prompt
/lagune-verify
```

**パスを指定**

```prompt
/lagune-verify src/routes/upload.ts
```

**優先度で指定**

```prompt
/lagune-verify 緊急と重要
```

## 仕組み

harden が記録した各箇所のコードを読み、記録の内容と本当に一致しているかを確認します。証明とは、この突き合わせ、つまりコードと記録の照合です。各対策には、次の 3 つの判定のいずれかが下されます：

| 判定                         | 意味                                                            |
| ---------------------------- | --------------------------------------------------------------- |
| ✅ Risk closed               | コードが記録の内容どおりに動作している。                        |
| ❌ Risk not closed           | 対策はまだ完了していない。verify は harden に戻るよう案内する。 |
| ❓ Cannot tell from the code | コードだけでは根拠が確認できない。                              |

解消が証明されたリスクは、確認を取ったうえでクローズし、チェーンから外します。たとえば：

- **ファイルのアップロード**（判定：**✅ Risk closed**）
  - _証明の方法_：アップロードのハンドラーを読み、ファイルの内容から実際の種類を判別し、サイズ制限を適用し、それ以外はすべて拒否していることを確認しました。記録の内容と完全に一致しています。
  - _根拠_：ファイルの内容から実際の種類を判別している `handleUpload` 関数です。

リスクが解消されていなければ、verify はそのことをはっきり伝え、修正がまだ完了していないため [`/lagune-harden`](https://lagune.ai/ja-JP/docs/commands/harden) に戻るよう案内します。

**ヒント**

- 堅牢化の記録だけを土台にしています。
- コードは判定のために読むだけで、判定を通すために対策を弱めたり、コードを書き換えたりすることは決してありません。
- 再実行すると判定を現状と照合して更新し、古くなった判定は外れ、解消済みでなくなったリスクは再び指摘されます。
- リスクの解消が証明されると、一度だけ確認したうえで、その検出事項をチェーン全体（detect、plan、harden、追跡）から取り除きます。
- 独自のレポートは作成せず、各判定は `.lagune/memory/harden.md` 内の対応する対策のブロックに記録されます。harden は次回の実行時にそれを読み込みます。

**harden に依存**

verify は [`/lagune-harden`](https://lagune.ai/ja-JP/docs/commands/harden) を土台にしています。

## サイクルが閉じる

対象範囲のすべてがクローズされると、サイクルは静止状態になります。再び開くのは、コードが変わったときだけです。セキュリティはクローズ可能なので、このフローは終わりのないループではなく、終着点を持ちます。

## よくある質問

### Lagune は修正をどのように検証しますか？

/lagune-verify がコードを読み、harden が記録した内容と突き合わせて、Risk closed（リスク解消）、Risk not closed（リスク未解消）、Cannot tell from the code（コードからは判断できない）の 3 つの判定のいずれかを返します。

### クローズとは何ですか？

verify がリスクの解消を証明すると、その検出事項はクローズされます。確認を得たうえでチェーン全体から取り除かれ、以後は再処理されません。

### セキュリティの作業を完了させることはできますか？

はい。SDH はクローズ可能です。解消が証明された検出事項はクローズされるため、フローは終わりのないループではなく、終着点を持ちます。

---

# カテゴリ

> Lagune プロジェクトで使える専門知識のカテゴリと、その変更方法を解説します。OWASP から、JavaScript、Python、Go、Rust の言語別の堅牢化までを扱います。

正規 URL: https://lagune.ai/ja-JP/docs/categories
言語: ja-JP
原文: https://lagune.ai/docs/categories
最終更新日: 2026-11-03

**Lagune** は組み込みの [**専門知識**](https://lagune.ai/ja-JP/docs/catalog) を **13 のカテゴリ**に分類しています。プロジェクトで使うカテゴリによって、どの組み込みの専門知識がプロジェクトの [**カタログ**](https://lagune.ai/ja-JP/docs/catalog) に入るかが決まります。カテゴリは、システムが何をするかを扱うものと、何の言語で書かれているかを扱うものの 2 種類に分かれます。

カテゴリがひとつも記録されていない間、プロジェクトは `owasp` だけを使います。[`/lagune-charter`](https://lagune.ai/ja-JP/docs/commands/charter) は、プロジェクトを読み取った結果から裏付けの得られたカテゴリをすべて記録します。カテゴリはいつでも自分で変更できます。

## システムが何をするか

| カテゴリ | キー      | 堅牢化の対象                                                                                                      |
| -------- | --------- | ----------------------------------------------------------------------------------------------------------------- |
| OWASP    | `owasp`   | OWASP が追跡するアプリケーションセキュリティのリスク：インジェクション、アクセス制御の不備、認証や暗号化の失敗    |
| インフラ | `infra`   | コンテナー、ワークロード、サーバーレスの設定：Dockerfile、Compose、Pod のセキュリティ、FaaS の IAM とトリガー     |
| AI / LLM | `ai`      | AI や LLM との連携を、プロンプトインジェクションや、安全でないツール、エージェント、検索、MCP の組み込みから守る  |
| Lovable  | `lovable` | AI が生成した Supabase アプリ（Lovable など）：RLS の不備、漏洩した `service_role` キー、安全でないデフォルト設定 |

## 何の言語で書かれているか

| カテゴリ   | キー         | 堅牢化の対象                                                                                                            |
| ---------- | ------------ | ----------------------------------------------------------------------------------------------------------------------- |
| JavaScript | `javascript` | 各ランタイムでの `eval` や `child_process` による RCE、パストラバーサル、プロトタイプ汚染                               |
| Python     | `python`     | `pickle` や YAML のデシリアライズによる RCE、`str.format` による文字列トラバーサル、クラス汚染                          |
| Rust       | `rust`       | 健全でない `unsafe` API、`transmute` の誤用、整数オーバーフロー、FFI 境界での未定義動作                                 |
| C / C++    | `c-cpp`      | コード実行につながるフォーマット文字列のバグ、バッファーオーバーフロー、境界外書き込み                                  |
| PHP        | `php`        | 型の相互変換（type juggling）による認証回避、オブジェクトインジェクションのガジェットチェーン、安全でないデフォルト設定 |
| Go         | `go`         | typed nil インターフェースのバグ、goroutine のデータ競合、セキュリティに関わる処理での安全でない並行処理                |
| Java       | `java`       | リモートコード実行に至る `ObjectInputStream` のデシリアライズのガジェットチェーン                                       |
| Ruby       | `ruby`       | リモートコード実行に到達する `Marshal.load` や YAML のデシリアライズのガジェットチェーン                                |
| .NET / C#  | `dotnet`     | `BinaryFormatter` のデシリアライズによる RCE と、XSS につながるエンコーダーの回避                                       |

**ヒント**

**Lagune** は言語に依存しません。プロジェクトが何の言語で書かれていても、フロー全体でそのまま読み取れます。これらのカテゴリは、特定の言語に固有の落とし穴をさらに深く掘り下げるだけです。

## いつでも追加・削除できる

カテゴリは出発点であり、一度選んだら変えられないものではありません。今のプロジェクトに合うものを使い、`write add` と `write remove` でキーを指定して、いつでも変更できます。ターミナルで `--categories` に値を付けずに実行すると、対話式の選択画面が開きます（スペースキーで選択の切り替え、Enter キーで確定、何も選ばなければスキップ）。ターミナル以外では、そのあとにカテゴリを続けて指定します。

**追加**

```bash
npx lagune write add --categories # interactive
npx lagune write add --categories owasp
npx lagune write add --categories owasp rust
```

**削除**

```bash
npx lagune write remove --categories # interactive
npx lagune write remove --categories owasp
npx lagune write remove --categories owasp rust
```

最初の `write add` や `write remove` は `owasp` を起点にするため、カテゴリをすべて削除すると、デフォルトに戻るのではなく空のリストになります。変更はすべて `.lagune/configs.json` に記録されるので、チーム全員が同じカテゴリの組み合わせで作業できます。

## プロジェクトで使っているカテゴリを確認する

`read list --categories` は、すべてのカテゴリと、それぞれをプロジェクトで使っているかどうかを表示します：

```bash
npx lagune read list --categories
# Categories
#   • owasp       [used]       Harden against the application security risks OWASP tracks
#   • javascript  [available]  Harden JavaScript and its runtimes
#   • php         [available]  Harden PHP against type-juggling auth bypass
#   • go          [available]  Harden Go against typed-nil interface bugs
#   ...
#
# No category is recorded yet, so this project uses the default: owasp.
```

各カテゴリにどの専門知識が含まれるかは、[**カタログ**](https://lagune.ai/ja-JP/docs/catalog) を参照してください。[`/lagune-specialize`](https://lagune.ai/ja-JP/docs/commands/specialize) で作成した独自の専門知識は、どのカテゴリを選んでいてもカタログに加わります。

## よくある質問

### カテゴリはどうやって追加しますか？

カテゴリのキーを --categories に渡します。たとえば npx lagune write add --categories javascript のように実行します。カテゴリがまだ記録されていない間は、charter もプロジェクトを読み取った結果から裏付けの得られたカテゴリを記録します。

### カテゴリは複数使えますか？

はい。同じ行に続けて並べて指定します。

### プロジェクトにはどのカテゴリを使えばいいですか？

まずはデフォルトの owasp から始め、使っている言語や技術スタックのカテゴリを追加してください。専門知識は必要なときだけ読み込まれるので、フェーズがそのカテゴリの専門知識を必要とするまでは、カテゴリを追加しても何のコストもかかりません。

---

# カタログ：必要なときに読み込むセキュリティの専門知識

> プロジェクトのカタログにある専門知識がどう読み込まれるかを解説します。フェーズが必要なときに読み込むほか、自分で直接読み込むこともできます。

正規 URL: https://lagune.ai/ja-JP/docs/catalog
言語: ja-JP
原文: https://lagune.ai/docs/catalog
最終更新日: 2026-11-03

🧠 **Lagune** の専門知識は、特定の分野に絞った、言語に依存しないセキュリティの知識モジュールです。必要なときだけ読み込まれ、デフォルトで読み込まれることはありません。専門知識はコマンドではありません。プロジェクトのカタログとは、そのプロジェクトが使う専門知識の集まりで、プロジェクトの [カテゴリ](https://lagune.ai/ja-JP/docs/categories) に属する組み込みの専門知識と、プロジェクト独自の専門知識からなります。detect フェーズと verify フェーズは実行中にこれらを参照します。また、いつでも自分で直接読み込むこともできます。

**概要**

*インタラクティブなカタログ概要は Web ページにあります。組み込みの専門知識はすべて下の表に載っています。*

**仕組み**

## 自分で実行する

専門知識を直接使うには、エージェントに `read catalog <name>` で読み込むよう頼み、同じプロンプトにタスクを書きます。すると、その知識が依頼した内容に生かされます。どんなプロンプトでも使え、**Lagune** のフローと関係のないプロンプトでも構いません。

たとえば、**Python** で安全な **RegExp** のコレクションを生成する、自由形式のプロンプトを直接書く場合：

```prompt
`npx lagune read catalog regex` で regex の専門知識を読み込んでから、@src/utils/regex.py にメールアドレスとユーザー名を検証する正規表現のコレクションを作成してください。
```

この場合、決定論的なフックで各 **RegExp** に **ReDoS** の危険がないかをテストし、安全なものだけを残して、次のような結果を生成します：

```python
import re

EMAIL = re.compile(r"^[a-zA-Z0-9._%+-]+@[a-zA-Z0-9.-]+\.[a-zA-Z]{2,}$")
USERNAME = re.compile(r"^[a-zA-Z0-9_]{3,20}$")

def is_email(value: str) -> bool:
    return EMAIL.match(value) is not None

def is_username(value: str) -> bool:
    return USERNAME.match(value) is not None
```

**ReDoS チェッカーを試す**

[**devina.io/redos-checker**](https://devina.io/redos-checker) で、パターンを自分でテストできます。

## 組み込みの専門知識

組み込みの専門知識は [**カテゴリ**](https://lagune.ai/ja-JP/docs/categories) ごとにまとめられています。**Lagune** に同梱されているのは次のとおりです：

| 専門知識              | カテゴリ                    | 対象                                                                                                                     |
| --------------------- | --------------------------- | ------------------------------------------------------------------------------------------------------------------------ |
| `regex`               | `owasp`                     | **ReDoS**：細工された入力で処理が爆発的に重くなるパターン。                                                              |
| `network`             | `owasp`                     | **SSRF とリダイレクト**：ユーザーが指定する取得先やリダイレクト先。                                                      |
| `interpreter`         | `owasp`, `lovable`          | **コードインジェクション**：`eval`、動的な include、名前によるディスパッチ。                                             |
| `sql`                 | `owasp`                     | **リレーショナルデータベース**：インジェクション、ORM の生クエリ呼び出し、権限、データベースエンジンから到達できる範囲。 |
| `path`                | `owasp`                     | **ファイルシステムのパス**：パストラバーサル、ヌルバイト、NTFS のストリーム、不正なファイルの配置。                      |
| `upload`              | `owasp`                     | **ファイルアップロード**：種類とシグネチャ、悪意のある内容、保存先、制限。                                               |
| `access-control`      | `owasp`, `lovable`          | **認証・認可・セッション**：IDOR、マスアサインメント、テナント、セッション。                                             |
| `credential-endpoint` | `owasp`, `lovable`          | **推測攻撃とボット**：総当たり攻撃、パスワードスプレー、リスト型攻撃、スロットリング。                                   |
| `federation`          | `owasp`                     | **トークンの信頼性**：OAuth/OIDC、SAML、JWT の検証、QR ログイン。                                                        |
| `http-request`        | `owasp`                     | **リクエストの出所**：CSRF、CORS の設定ミス、偽装されたクライアント IP。                                                 |
| `transport`           | `owasp`                     | **通信経路のセキュリティ**：TLS の設定、HTTPS と平文通信、HSTS、証明書ピンニング。                                       |
| `crypto`              | `owasp`, `lovable`          | **保存データの暗号化**：脆弱なアルゴリズムや独自アルゴリズム、CSPRNG、鍵管理。                                           |
| `secrets`             | `owasp`, `lovable`          | **ハードコードされた認証情報**：ソースコードに直接書かれたキー、トークン、パスワード。                                   |
| `api-endpoint`        | `owasp`                     | **REST 以外の API**：GraphQL、gRPC、WebSocket の認可、DoS、スキーマ。                                                    |
| `payment`             | `owasp`, `lovable`          | **決済フロー**：サーバー側での決済ゲートウェイの検証、署名付きコールバック、冪等性。                                     |
| `xml`                 | `owasp`                     | **XML の解析**：XXE、外部エンティティ、Billion Laughs 型のエンティティ展開。                                             |
| `csv`                 | `owasp`                     | **数式インジェクション**：`=`/`+`/`-`/`@` で始まるスプレッドシートのセル。                                               |
| `container`           | `owasp`, `infra`            | **コンテナーの設定**：root での実行、ケーパビリティ、ソケットのマウント、イメージの堅牢化。                              |
| `infra`               | `infra`                     | **Infrastructure as Code**：Terraform、Dockerfile、GitHub Actions。                                                      |
| `serverless`          | `owasp`, `infra`, `lovable` | **FaaS の関数**：最小権限の IAM、イベント入力、コンテキスト、シークレット。                                              |
| `llm`                 | `ai`, `lovable`             | **AI/LLM のリスク**：プロンプトインジェクション、AI に与える権限、RAG、MCP、出力。                                       |
| `supabase`            | `lovable`                   | **Supabase のバックエンド**：デフォルトで無効な RLS、AI が誤って生成したポリシー、キーの仕組み。                         |
| `browser`             | `javascript`, `lovable`     | **クライアント側のリスク**：XSS、CSP、フレームへの埋め込み、ストレージなど。                                             |
| `javascript`          | `javascript`                | **言語レベルのリスク**：RCE、プロトタイプ汚染など。                                                                      |
| `python`              | `python`                    | **言語レベルのリスク**：`pickle` による RCE、クラス汚染、`-O` など。                                                     |
| `rust`                | `rust`                      | **`unsafe` の健全性**：safe な呼び出し元から生じる UB、`transmute`、オーバーフロー。                                     |
| `java`                | `java`                      | **デシリアライズとモバイルコード**：`readObject` のチェーン、オブジェクトの乗っ取り。                                    |
| `ruby`                | `ruby`                      | **デシリアライズと `open`**：`Marshal` や YAML によるオブジェクトの復元、パイプの特殊な挙動。                            |
| `php`                 | `php`                       | **型の相互変換と `unserialize`**：マジックハッシュ、POP チェーン。                                                       |
| `go`                  | `go`                        | **typed nil とデータ競合**：`nil != nil`、メモリを共有する goroutine。                                                   |
| `c-cpp`               | `c-cpp`                     | **フォーマット文字列**：`printf(user_input)`、`%n` による任意アドレスへの書き込み。                                      |
| `dotnet`              | `dotnet`                    | **プラットフォームレベルのリスク**：`BinaryFormatter` による RCE、`@Html.Raw`、列挙型の検証漏れ。                        |

組み込みの知識のほとんどは OWASP をもとにまとめたものです。各専門知識と、その元になった OWASP の正式な攻撃ページや Cheat Sheet ページとの対応の全体は、[**OWASP の出典**](https://lagune.ai/ja-JP/docs/references/owasp-sources) を参照してください。一部の技術スタック固有のモジュールは、OWASP ではなくベンダー自身のガイダンスをもとにしています。たとえば `supabase` は、Supabase のドキュメントと CVE-2025-48757 に基づいています。

## 独自の専門知識

組み込みの専門知識は、知識ファイルを 1 つとインデックスの行を 1 つ追加するだけで増やせ、新しいコマンドは必要ありません。独自の専門知識も同じ方法で、[`/lagune-specialize`](https://lagune.ai/ja-JP/docs/commands/specialize) を使って追加できます。記事やトピックを指定すると、それをもとに新しい専門知識をまとめてプロジェクトに加えます。ファイルは `.lagune/catalog/` の下に置かれ、そのエントリは `.lagune/configs.json` に記録されます。独自の専門知識はカテゴリにかかわらず常にカタログに含まれ、組み込みと同じ名前のものは、組み込みのほうより優先されます。

**Lagune は内部で、必要に応じて専門知識を自動的に読み込む**

detect フェーズや verify フェーズは、ある専門知識が扱う状況に出会うと、`read catalog <name>` でその専門知識を自ら読み込みます。これはフェーズの一部として自動的に行われるため、手作業で読み込む必要はありません。

## 使える専門知識を調べる

ターミナルでプロジェクトのカタログを一覧表示すると、専門知識が 1 行に 1 つずつ、タグと一緒に表示されます：

```bash
npx lagune read catalog
# regex: Regular Expression [required]
# network: Requests, Webhook, URL Fetch, Socket, IMDS, Redirect
# interpreter: Evaluator, Sink, Shell, Dynamic Execution
# ...
```

`[required]` の付いた専門知識は、作業の内容にかかわらず常に適用されます。一覧にどの組み込みの専門知識が含まれるかは、プロジェクトの [**カテゴリ**](https://lagune.ai/ja-JP/docs/categories) によって決まります。

**専門知識はデフォルトでは読み込まれない**

すべてのチェックをデフォルトで実行するのではなく、プロジェクトの実態に合った知識だけを取り込みます。

## よくある質問

### Lagune の専門知識とは何ですか？

特定の分野に絞った、言語に依存しないセキュリティの知識モジュールです。必要なときだけ読み込まれ、デフォルトで読み込まれることはありません。エージェントのスキルとは違い、コマンドではありません。

### プロジェクトのカタログとは何ですか？

プロジェクトが使う専門知識の集まりで、プロジェクトのカテゴリに属する組み込みの専門知識と、プロジェクト独自の専門知識からなります。カテゴリが記録されていない間は、OWASP だけを使います。

### 専門知識はデフォルトで読み込まれますか？

いいえ。プロジェクトの実態に合わせて、必要なときだけ読み込まれます。

### 専門知識を直接読み込むにはどうすればいいですか？

タスクと同じプロンプトで、エージェントに npx lagune read catalog <name> を実行するよう依頼してください。

---

# /lagune-specialize: プレーンテキストでセキュリティの専門知識を学習させる

> 渡したセキュリティの資料やトピックを、必要なときに読み込まれる新しい専門知識にまとめます。

正規 URL: https://lagune.ai/ja-JP/docs/commands/specialize
言語: ja-JP
原文: https://lagune.ai/docs/commands/specialize
最終更新日: 2026-11-03

🎓 渡した資料やトピックから、**Lagune** に新しい専門知識を教えます。

資料を読み込み、[組み込みの専門知識](https://lagune.ai/ja-JP/docs/catalog) とまったく同じ形式の、対象を絞った防御専用の専門知識にまとめます。そのため、以後は detect フェーズと verify フェーズが、ほかの専門知識と同じようにこれを読み込みます。行うのは監査と説明だけで、攻撃用の入力やエクスプロイトを書くことも、コードに手を加えることもありません。

**記事から**

```prompt
# リンクや参考資料：Lagune がそこから防御策をまとめます
/lagune-specialize https://owasp.org/www-community/attacks/SQL_Injection
```

**エクスプロイトから**

```prompt
# 攻撃を資料にする場合：それでも専門知識は防御のためのものです
/lagune-specialize "' OR 1=1 -- がクエリ文字列に SQL を差し込む"
```

**トピックから**

```prompt
# または、扱う内容を挙げるだけでも構いません
/lagune-specialize SQL インジェクション
```

**攻撃は資料にできても、出力にはならない**

防御が目的であれば、攻撃を題材にしても問題ありません。エクスプロイトの解説記事は、防御策にまとめるための学習材料になります。生成される専門知識は常に監査と説明を行うもので、実際に動くエクスプロイトやペイロード、検知回避の手段を生み出すことはありません。

## 書き出すもの

結果はプロジェクト内の 2 つのファイルで、コードと一緒にコミットしてレビューできます：

- 専門知識そのもの。`.lagune/catalog/<name>.md` に、[組み込みの専門知識](https://lagune.ai/ja-JP/docs/catalog) と同じ形式で書き出されます。
- `.lagune/configs.json` 内のエントリ。プロジェクトはここに独自の専門知識を登録し、カタログはそれを組み込みの専門知識と統合します。

その後、カタログを一覧表示して、新しいエントリが含まれていることを確認します。独自の専門知識は、カテゴリにかかわらず常にカタログに含まれます。コマンドを追加したり、パッケージに手を加えたりする必要はありません。新しい専門知識は、自分のプロジェクトに書き込まれる知識ファイル 1 つとインデックスのエントリ 1 つだけです。

## 上書きせず、磨き上げる

すでにある名前で専門知識を作ると、`regex` のような組み込みのものでも、以前に自分で作ったものでも、現在のファイルを置き換えずに**照合して更新**します。既存の内容を読み、新しい知識を取り込み、今も有効な部分は残し、変わった部分は書き直します。確認されないまま破棄される内容はありません。自分の専門知識は同じ名前の組み込みの専門知識より優先されるため、組み込みの専門知識を失うことなく、自分のプロジェクト向けに磨き上げられます。

**ヒント**

- 新しい専門知識は、組み込みのものとまったく同じように読み込まれます。detect フェーズと verify フェーズが必要に応じて読み込むほか、`npx lagune read catalog <name>` で自分で読み込み、タスクを与えることもできます。
- 資料の出どころ（記事、著者、リンク、標準規格）が特定できる場合は、専門知識にその出典を明記します。トピックだけを渡した場合、出典は付きません。

**注記**

**呼び出したときにだけ実行されます**：エージェントが自分から開始することはありません。

## よくある質問

### セキュリティの専門知識を独自に追加するにはどうすればいいですか？

資料やトピックを付けて /lagune-specialize を実行します。防御専用の専門知識にまとめて .lagune/catalog/<name>.md に書き出し、.lagune/configs.json にエントリを追加します。

### Lagune はエクスプロイトの解説記事から学習できますか？

はい。ただし資料としてであり、出力としてではありません。攻撃は資料にはなっても、生み出されるものにはなりません。specialize が攻撃用の入力やエクスプロイトを書くことはありません。

### specialize は組み込みの専門知識を上書きしますか？

いいえ。上書きはせず、内容を磨き上げます。

---

# /lagune-prove: 防御専用の概念実証（PoC）

> 検出事項を 1 件ずつ、実行できる防御専用の概念実証（PoC）と、責任ある開示のためのセキュリティアドバイザリに変えます。

正規 URL: https://lagune.ai/ja-JP/docs/commands/prove
言語: ja-JP
原文: https://lagune.ai/docs/commands/prove
最終更新日: 2026-11-03

🧪 detect で見つかった検出事項を 1 件ずつ、責任ある開示に使える、実行可能な防御専用の証拠に変えます。

detect マップにある検出事項ごとに、それ単体で読めるセキュリティアドバイザリと、**安全な経路**を検証するテストを書き出します。そのため、テストは問題が残っている間は失敗し、コードが修正されると成功します。

**ヒント**

**Lagune** のテストは `.lagune/` の下に分離して置かれ、プロジェクト自身のテストスイートとは別に管理されます。

## 実行方法

**すべての検出事項**

```prompt
/lagune-prove
```

**名前を指定した検出事項**

追跡中の検出事項を名前で確認します：

```prompt
npx lagune read list --findings

# Findings
#   ...
#   • ユーザー検索での SQL インジェクション
#   ...
```

```prompt
# 次に、そのうちの 1 つを証明します
/lagune-prove ユーザー検索での SQL インジェクション
```

## 仕組み

各検出事項が指すソースコードを読み、証明できた検出事項ごとに `.lagune/proofs/` の下に 1 つのディレクトリを作ります。各ディレクトリには、ちょうど 2 つのファイルが入ります：

| ファイル                           | 内容                                                                                                                                                  |
| ---------------------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------- |
| `report.test.mjs`（または `.cjs`） | テスト本体。プロジェクトですでに Poku を使っていれば Poku で、そうでなければ Node.js 標準のテストランナーで動くため、何もインストールする必要がない。 |
| `report.md`                        | 自己完結したセキュリティアドバイザリ。深刻度、影響、再現方法、実行コマンドを含み、単体で読める。                                                      |

証明は常に JavaScript で書かれるため、プロジェクトが何の言語で書かれていても、そのまま持ち運べます。インデックスの `README.md` には、すべての証明へのリンクと、それらをまとめて実行する 1 つのコマンドが載っています。

**ヒント**

- **任意かつ独立したコマンド**です。5 つのフェーズのひとつではなく、追跡のチェーンにも含まれません。
- 書き込み先は `.lagune/proofs/` だけです。フェーズの成果物やコードは読み取るだけで、手を加えることはありません。
- テストで問題を再現できない検出事項には証明を作らず、その箇所について [`/lagune-detect`](https://lagune.ai/ja-JP/docs/commands/detect) を実行し、記録を照合して更新するよう促します。
- もう一度実行すると、証明を照合して更新します。なくなった検出事項や、もう再現しない検出事項は、そのディレクトリが削除されます。

**注記**

**呼び出したときにだけ実行されます**：エージェントが自分から開始することはありません。

**detect の結果を前提とする**

prove は [`/lagune-detect`](https://lagune.ai/ja-JP/docs/commands/detect) が作る detect マップを読むため、先に detect を実行してください。

## 防御専用で、許可された範囲のみ

何かを生成する前に、対象をテストする権限があることを確認します。また、実際に動くエクスプロイト、攻撃用のペイロード、検知回避の手段を求める依頼はすべて断ります。証明が示すのは安全な挙動であり、攻撃用の入力を出力することはありません。

## 証明から開示へ

証明できた検出事項の 2 つのファイルは、脆弱性を報告するために、まとめて 1 つの**非公開の GitHub Gist** に入れます。これらはまだ公開されていない、現在も残っている問題の証拠です。そのため、`.gitignore` を `.lagune/proofs/` の中に置いて、どのコミットにも含まれないようにしています。メンテナーが問題を解決するまでは、その Gist を通じてのみ共有してください。

**Lagune** のチェーンで検出事項をクローズするのは、引き続き [`/lagune-harden`](https://lagune.ai/ja-JP/docs/commands/harden) と [`/lagune-verify`](https://lagune.ai/ja-JP/docs/commands/verify) の役割です。prove は証拠を作るだけで、何もクローズしません。

## よくある質問

### Lagune はエクスプロイトを生成しますか？

いいえ。/lagune-prove が書き出すのは防御専用の証拠です。安全な経路を検証するテスト（問題が残っている間は失敗し、コードが修正されると成功します）と、責任ある開示のためのセキュリティアドバイザリです。

### prove は何を出力しますか？

検出事項ごとに 2 つのファイルです。テスト（report.test.mjs または .cjs）と、セキュリティアドバイザリ（report.md）です。

### Lagune が見つけたバグを、責任ある形で開示するにはどうすればいいですか？

prove は自己完結したセキュリティアドバイザリを書き出します。責任ある開示の手順に沿って、非公開の GitHub Gist などの非公開の経路で共有できます。

---

# agent フック：上限のないエージェントループを検出する

> コマンドラインから、ステップ数や時間に上限のないエージェントや LLM の呼び出しをコードベース全体でスキャンしたり、1 つの呼び出しを判定したりできます。

正規 URL: https://lagune.ai/ja-JP/docs/hooks/agent
言語: ja-JP
原文: https://lagune.ai/docs/hooks/agent
最終更新日: 2026-11-03

`agent` フックは、**ターン数、予算、時間のどれにも上限を設けずにループするエージェントランタイム**を指摘します。自律動作の暴走を招くこの穴があると、細工された入力ひとつで、コストが際限なく膨らんだり、プロンプトインジェクションがエスカレートしたりします。**言語を識別**して動作し、**JavaScript**（**Claude** エージェント SDK の `query` ランタイム）と **Python**（**LangChain**、**LangGraph**、**CrewAI**、**OpenAI Agents**）という 2 つのエージェントフレームワークのエコシステムに対応しています。また、[`llm` 専門知識](https://lagune.ai/ja-JP/docs/catalog) を支える決定論的なエンジンでもあり、**scan** モードまたは **check** モードで自分で実行することもできます。

## 実行方法

**コードベースをスキャン**

```bash
npx lagune read agent                # scans the whole project
npx lagune read agent --dir src/ai   # scans a directory
npx lagune read agent --file chat.ts # scans a single file
```

**呼び出しをチェック**

```bash
npx lagune read agent --lang javascript --pattern 'query({ prompt })'                           # => uncapped
npx lagune read agent --lang javascript --pattern 'query({ prompt, options: { maxTurns: 5 } })' # => safe
npx lagune read agent --lang python --pattern 'AgentExecutor(agent=a, max_iterations=None)'     # => uncapped
```

**Uncapped agent loops found** の下に並ぶ各行は、エージェント SDK をインポートしているファイル内で、Claude エージェント SDK の `query` ランタイムをターン数、予算、時間のどれにも上限を設けずに呼び出している箇所（JavaScript、デフォルトでは上限なし）か、`max_iterations=None` / `max_turns=None` のようにフレームワークのデフォルトの上限を明示的に外している箇所（Python、デフォルトでは上限あり）です。どちらが見つかっても、0 以外の終了コードで終了します。Vercel AI SDK の `generateText`/`streamText` はデフォルトで 1 ステップしか実行しない（`stopWhen: stepCountIs(1)`）ため、そのまま呼び出してもループせず、指摘されません。また、通常の `db.query(...)` がエージェントの呼び出しと誤認されることもありません。何も見つからなければ `no uncapped agent loops found` と出力します。

## 判定の読み方

| 判定       | 意味                                                                                                            |
| ---------- | --------------------------------------------------------------------------------------------------------------- |
| `uncapped` | 上限のない `query` ランタイムの呼び出し（JS）、または上限の明示的な解除（`=None`、Py）。                        |
| `safe`     | 上限を設定した `query` の呼び出し、1 ステップだけの生成、またはデフォルトで上限のあるフレームワークの呼び出し。 |
| `invalid`  | 判定できるエージェントの呼び出しがコードスニペットに見当たらない。                                              |

### CLI オプション

| オプション  | 値               | 説明                                                                                              |
| ----------- | ---------------- | ------------------------------------------------------------------------------------------------- |
| `--pattern` | コードスニペット | 1 つの呼び出しをチェックする。繰り返し指定すると複数をチェックし、1 行に 1 つずつ判定を出力する。 |
| `--lang`    | 言語             | `--pattern` を使うときは必須：`javascript` または `python`。                                      |
| `--dir`     | ディレクトリ     | スキャン対象をディレクトリに絞る。繰り返し指定でき、`--file` と併用できる。                       |
| `--file`    | ファイル         | スキャン対象を 1 つのファイルに絞る。繰り返し指定でき、`--dir` と併用できる。                     |

オプションを指定しなければ、プロジェクト全体をスキャンします。`--pattern` には `--lang` が必要で、`--dir` や `--file` とは併用できません。

**ベストエフォートであり、網羅的ではない**

自前で実装したエージェントループは、どの言語で書かれていても静的スキャンでは捉えられません。完全な一覧ではなく、確かな最低ラインとして扱ってください。

**ヒント**

フックが判定するのは上限だけで、機能の範囲の絞り込み、信頼レベルの混在、認可といった判断は、引き続き [`llm` 専門知識](https://lagune.ai/ja-JP/docs/catalog) が担います。

## よくある質問

### エージェントループに上限を設けるべきなのはなぜですか？

上限のないエージェントは、際限のない再帰やコスト、プロンプトインジェクションのエスカレーションへと誘導されるおそれがあります。maxTurns/maxBudgetUsd/stopWhen/signal を設定すれば歯止めがかかり、agent フックはどれも設定していない query ランタイムの呼び出しを指摘します。

---

# cors フック：CORS オリジンを監査する

> コマンドラインから、ソースコードをスキャンして回避可能な CORS オリジン許可リストを探したり、1 つのオリジン値の許可範囲が広すぎないかを判定したりできます。

正規 URL: https://lagune.ai/ja-JP/docs/hooks/cors
言語: ja-JP
原文: https://lagune.ai/docs/hooks/cors
最終更新日: 2026-11-03

`cors` フックは [`http-request` 専門知識](https://lagune.ai/ja-JP/docs/catalog) を支える決定論的なエンジンで、自分で実行することもできます。1 つのコマンドで 2 つのモードが使えます：**scan** モードはソースコードをスキャンして**回避可能なオリジン許可リスト**（攻撃者のホストがすり抜けられる、ホスト検証用の正規表現）を探し、**score** モードは 1 つの **CORS オリジン**の値を `wildcard`、`null`、`safe` のいずれかに判定します。

## コードベースをスキャンする

フラグを付けなければ、プロジェクト全体をスキャンします。

**プロジェクト全体**

```bash
npx lagune read cors
```

**ディレクトリ**

```bash
npx lagune read cors --dir src/server
```

**1 つのファイル**

```bash
npx lagune read cors --file internal/auth/origin.go
```

回避可能な許可リストを、ファイルごとにまとめて 1 つの見出しの下に一覧表示します。信頼するホストのサフィックスより前のオーソリティ部分に `.+`/`.*` があるホスト検証（`^https?://.+\.trusted\.com`）では、`your-site.com.attacker.com` のような攻撃者のホストがすり抜けてしまいます。

```text
Origin-allowlist patterns with a greedy wildcard (bypassable, review):

internal/auth/origin.go
  ^https?://.+\.trusted\.com
```

これは確定した検出事項ではなく、要確認の手がかりです。その正規表現が実際の信頼判断を左右しているかどうかはテキストからは判定できないため、スキャンによって終了コードが変わることはありません。一つひとつ読んで、許可リストが完全一致で比較しているかを確認してください。何も見つからなければ、1 行だけ出力します。

```bash
npx lagune read cors --dir src/clean
# => no bypassable origin allowlist found
```

## オリジンを判定する

各オリジンを `--origin` で渡します。フックはオリジンごとに 1 語を出力し、`wildcard` または `null` が 1 つでもあれば 0 以外の終了コードで終了します。

**1 つのオリジン**

```bash
npx lagune read cors --origin '*'                       # => wildcard
npx lagune read cors --origin 'null'                    # => null
npx lagune read cors --origin 'https://app.example.com' # => safe
```

**複数のオリジン**

`--origin` を繰り返し指定すると、許可リスト全体を 1 回の呼び出しで判定でき、指定した順に 1 行に 1 つずつ判定を出力します。

```bash
npx lagune read cors \
  --origin 'https://app.example.com' \
  --origin '*' \
  --origin 'null'
# => safe
# => wildcard
# => null
```

| 判定       | 意味                                                                                                              |
| ---------- | ----------------------------------------------------------------------------------------------------------------- |
| `safe`     | `*`、`null`、`*` を使ったグロブのいずれでもない。オリジンの形式が正しいことまでは保証しない。                     |
| `wildcard` | `*`、またはサブドメイン、ホスト、ポートのグロブ：どのサイト（あるいは広範なサイト群）でもレスポンスを読み取れる。 |
| `null`     | `null` オリジン。サンドボックス化された iframe やリダイレクトで偽装できる。                                       |

許可を意味するのは `safe` だけです。また、`--origin` は値のオラクルです。判定するのはハンドラーではなく値なので、ハンドラーは `http-request` 専門知識で確認してください。

### CLI オプション

| オプション | 値           | 説明                                                                                  |
| ---------- | ------------ | ------------------------------------------------------------------------------------- |
| `--origin` | オリジン     | 1 つのオリジン値を判定する。繰り返し指定すると複数を判定し、1 行に 1 つずつ出力する。 |
| `--dir`    | ディレクトリ | スキャン対象をディレクトリに絞る。繰り返し指定でき、`--file` と併用できる。           |
| `--file`   | ファイル     | スキャン対象を 1 つのファイルに絞る。繰り返し指定でき、`--dir` と併用できる。         |

オプションを指定しなければ、プロジェクト全体をスキャンします。`--origin` は score モードで、`--dir` や `--file` とは併用できません。

**対象外の範囲**

スキャンが読み取るのは**回避可能な正規表現**という形で、`--origin` が判定するのはオリジンの**値**です。ソースコード上の次の 2 つのパターンは対象外です：リクエストの `Origin` の反射（サーバーが受け取った `Origin` をそのまま返す、または認証情報と組み合わせて返す）と、`endsWith` や部分文字列による緩い許可リストです。これらはコードを読んで見分け、[`http-request` 専門知識](https://lagune.ai/ja-JP/docs/catalog) の説明に沿って対処してください。

## よくある質問

### CORS の null オリジンが危険なのはなぜですか？

サンドボックス化された iframe や一部のリダイレクトは Origin: null を送信するため、null を信頼する許可リストは、そうしたコンテキストに読み取りアクセスを与えてしまいます。cors フックは、ワイルドカードと並んでこれも指摘します。

### 回避可能な CORS オリジン許可リストを見つけるにはどうすればよいですか？

コードベースに対して npx lagune read cors を実行します。信頼するサフィックスより前に貪欲なワイルドカードがあるホスト検証用の正規表現を指摘します。こうした正規表現では、your-site.com.attacker.com のような攻撃者のホストがすり抜けてしまいます。

---

# crypto フック：脆弱な暗号を検出する

> コマンドラインから、脆弱な暗号プリミティブをコードベース全体でスキャンしたり、1 つのコードスニペットを判定したりできます。

正規 URL: https://lagune.ai/ja-JP/docs/hooks/crypto
言語: ja-JP
原文: https://lagune.ai/docs/hooks/crypto
最終更新日: 2026-11-03

`crypto` フックは、非推奨の暗号方式、安全でないモード、破られたダイジェストといった**脆弱な暗号プリミティブ**を、呼び出し箇所で指摘します。**言語を識別**して動作し、各ファイルをその言語のルールで読み取るため、Python の構文が Rust のファイルで指摘されることはありません。また、[`crypto` 専門知識](https://lagune.ai/ja-JP/docs/catalog) を支える決定論的なエンジンでもあり、**scan** モードまたは **check** モードで自分で実行することもできます。

## 実行方法

**コードベースをスキャン**

```bash
npx lagune read crypto                # scans the whole project
npx lagune read crypto --dir src      # scans a directory
npx lagune read crypto --file hash.ts # scans a single file
```

**コードスニペットをチェック**

```bash
npx lagune read crypto --lang javascript --pattern 'createCipher("aes-256-cbc", k)' # => weak
npx lagune read crypto --lang python --pattern 'hashlib.md5(data)'                  # => review
npx lagune read crypto --lang go --pattern 'sha256.Sum256(data)'                    # => safe
```

スキャンは最大 2 つのセクションを出力します。**Weak cryptography found** は検出事項の一覧（DES/3DES/RC4/Blowfish/RC2、ECB モード）で、いずれも破られた暗号プリミティブのため、フックは 0 以外の終了コードで終了します。**Cryptography to review manually** は、フックだけでは判断できない手がかりの一覧です：MD5/SHA-1 のダイジェスト（セキュリティ用途では破られているものの、単なるチェックサムとしては正当なので、用途次第）、セキュリティ上重要な箇所での暗号論的に安全でない乱数生成器、またはタイミング攻撃に弱い比較です。何も見つからなければ `no weak cryptography found` と出力します。

## 判定の読み方

| 判定      | 意味                                                                                                                                 |
| --------- | ------------------------------------------------------------------------------------------------------------------------------------ |
| `weak`    | コードスニペットが、破られた暗号プリミティブ（DES/3DES、RC4、Blowfish、RC2、または ECB モード）を使っている。                        |
| `review`  | 用途によって判断が分かれるプリミティブ：MD5/SHA-1 のダイジェスト、またはセキュリティ上重要な箇所での暗号論的に安全でない乱数生成器。 |
| `safe`    | コードスニペットは暗号を使っているが、脆弱なプリミティブは見つからなかった。                                                         |
| `invalid` | 判定できる暗号の構文がコードスニペットに見当たらない。                                                                               |

### CLI オプション

| オプション  | 値               | 説明                                                                                                             |
| ----------- | ---------------- | ---------------------------------------------------------------------------------------------------------------- |
| `--pattern` | コードスニペット | 1 つのコードスニペットをチェックする。繰り返し指定すると複数をチェックし、1 行に 1 つずつ判定を出力する。        |
| `--lang`    | 言語             | `--pattern` を使うときは必須：javascript、python、go、java、kotlin、php、ruby、rust、csharp、c、cpp のいずれか。 |
| `--dir`     | ディレクトリ     | スキャン対象をディレクトリに絞る。繰り返し指定でき、`--file` と併用できる。                                      |
| `--file`    | ファイル         | スキャン対象を 1 つのファイルに絞る。繰り返し指定でき、`--dir` と併用できる。                                    |

オプションを指定しなければ、プロジェクト全体をスキャンします。`--pattern` には `--lang` が必要で、`--dir` や `--file` とは併用できません。

### 対応言語

スキャンはファイル拡張子をもとに次の言語を読み取り、それぞれの言語の暗号 API と照らし合わせてチェックします。

| 言語                        | 脆弱な暗号方式（検出事項）、ダイジェストと乱数生成器（要確認）                                                       |
| --------------------------- | -------------------------------------------------------------------------------------------------------------------- |
| **JavaScript / TypeScript** | `createCipher`、`CryptoJS.DES/RC4`、引用符付きの `*-ecb`／MD5/SHA-1 の `createHash`/`subtle.digest`／`Math.random()` |
| **Python**                  | pycryptodome の `DES/ARC4/Blowfish.new`、`algorithms.TripleDES`、`MODE_ECB`／`hashlib.md5/sha1`／`random.*`          |
| **Go**                      | `des.NewCipher`、`rc4.NewCipher`、`blowfish.NewCipher`、`NewECBEncrypter`／`md5/sha1.Sum`／`math/rand`               |
| **Java / Kotlin**           | `Cipher.getInstance("DES"/…/ECB")`／`MessageDigest.getInstance("MD5")`、`HmacMD5`／`java.util.Random`                |
| **PHP**                     | `openssl_encrypt("des-…"/"…-ecb")`、`mcrypt_*`／`md5()`/`sha1()`、`hash("md5", …)`／`rand()`/`mt_rand()`             |
| **Ruby**                    | `OpenSSL::Cipher.new("des-…")`、`:ECB`／`Digest::MD5/SHA1`／`rand()`/`Random`                                        |
| **Rust**                    | `Rc4::`、`Blowfish::`、`des::`、`ecb::`／`Md5::`、`Sha1::`、`Hmac<Md5>`／`SmallRng`/`XorShiftRng`                    |
| **C#**                      | `DES/TripleDES/RC2.Create`、`CipherMode.ECB`／`MD5/SHA1.Create`、`HMACMD5`／`new Random()`                           |
| **C / C++**                 | OpenSSL の `DES_*`/`RC4`/`EVP_des_*`、`EVP_*_ecb`／`MD5()`/`SHA1()`、`EVP_md5`／`rand()`/`random()`                  |

**ベストエフォートであり、網羅的ではない**

ソースコードをテキストとして読み取るため、実行時に組み立てられたプリミティブや、エイリアスの陰に隠れたもの、認識できない書き方のものは見逃すことがあります。この表は完全な一覧ではなく、確かな出発点として扱ってください。

**ヒント**

フックが保証するのは最低ライン（こうした構文が存在すること）で、鍵管理、IV の再利用、RSA のパディングといった判断は、引き続き [`crypto` 専門知識](https://lagune.ai/ja-JP/docs/catalog) が担います。

## よくある質問

### コードベースの脆弱な暗号をスキャンするにはどうすればよいですか？

フラグを付けずに crypto フックを実行します。破られた暗号方式と ECB モードは検出事項となり、0 以外の終了コードで終了します。MD5/SHA-1 のダイジェストは、セキュリティ用途では破られているものの単なるチェックサムとしては正当なため、要確認の手がかりとして扱います。

### crypto フックは Math.random() を指摘しますか？

セキュリティ上重要な箇所で要確認の手がかりとして挙げるだけで、自動的に検出事項にすることはありません。ジッターや UI の並び順に乱数を使うのは正当だからです。

---

# cvss フック：CVSS v4.0 ベクトルのスコアを算出する

> コマンドラインから 1 つまたは複数の CVSS v4.0 ベクトルのスコアを FIRST の計算ツールと同じ計算方法で算出し、それぞれをわかりやすい言葉で読み解けます。

正規 URL: https://lagune.ai/ja-JP/docs/hooks/cvss
言語: ja-JP
原文: https://lagune.ai/docs/hooks/cvss
最終更新日: 2026-11-03

`cvss` フックは **CVSS v4.0 ベクトル**のスコアを算出し、スコアと深刻度の区分を出力します。これは [`/lagune-plan`](https://lagune.ai/ja-JP/docs/commands/plan) が各修正に、[`/lagune-prove`](https://lagune.ai/ja-JP/docs/commands/prove) が各セキュリティアドバイザリに記載する評価です。フックはこうした評価を支える決定論的なエンジンで、[FIRST の計算ツール](https://www.first.org/cvss/calculator/4.0) と同じ計算方法を使っており、自分で実行することもできます。

## 実行方法

各ベクトルを `--vector` で渡します。フックはベクトルごとに、スコアと区分を 1 行で出力します。

**1 つのベクトル**

```bash
npx lagune read cvss --vector 'CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:H/VI:H/VA:H/SC:N/SI:N/SA:N'
# => 9.3, Critical
```

**複数のベクトル**

`--vector` を繰り返し指定すると、複数のベクトルのスコアを一度に算出し、指定した順に 1 行ずつ出力します。

```bash
npx lagune read cvss \
  --vector 'CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:H/VI:H/VA:H/SC:N/SI:N/SA:N' \
  --vector 'CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:H/VI:H/VA:H/SC:N/SI:N/SA:N/MAV:A'
# => 9.3, Critical
# => 8.7, High
```

**わかりやすい言葉で**

`--explain` を付けると、各メトリクスをわかりやすい言葉で読み解けます。Threat メトリクスや Environmental メトリクスでスコアが変わる場合は、Base スコア単体が先に表示されます。

```bash
npx lagune read cvss --explain --vector 'CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:H/VI:H/VA:H/SC:N/SI:N/SA:N/MAV:A'
# => 8.7, High
# =>   Base metrics alone: 9.3, Critical
# =>   Attack Vector: Network, modified to Adjacent
# =>   Attack Complexity: Low
# =>   ...
```

## 結果の読み方

| 区分       | スコア    |
| ---------- | --------- |
| `None`     | 0.0       |
| `Low`      | 0.1〜3.9  |
| `Medium`   | 4.0〜6.9  |
| `High`     | 7.0〜8.9  |
| `Critical` | 9.0〜10.0 |

Base メトリクスだけのベクトルは、最悪の場合、つまりすべてのセキュリティ要求度が High で、その欠陥が実際に攻撃に悪用されている状態を想定して、欠陥そのものを評価します。Environmental メトリクス（`MAV` などの Modified メトリクスと、`CR`、`IR`、`AR`）は特定のデプロイ環境に合わせて、Threat メトリクス（`E`）は悪用について判明している情報に合わせて、スコアを確定させます。

ベクトルが無効な場合は、`invalid vector:` に続けて問題点を出力し、フックは 0 以外の終了コードで終了します。

### CLI オプション

| オプション  | 値                  | 説明                                                                                                               |
| ----------- | ------------------- | ------------------------------------------------------------------------------------------------------------------ |
| `--vector`  | `CVSS:4.0` ベクトル | 1 つのベクトルのスコアを算出する。繰り返し指定すると複数を算出し、指定した順に 1 ベクトルにつき 1 行ずつ出力する。 |
| `--explain` |                     | 各評価行の下に、各メトリクスの説明をわかりやすい言葉で追加する。                                                   |

`--vector` は少なくとも 1 つ必要です。ベクトルを位置引数として単独で渡すことはないため、フラグと取り違えられることはありません。

**フラグの値として渡す理由**

各ベクトルはフラグの値として渡され、コマンドに埋め込まれることはありません。引用符やバッククォートを含む値も無害なままで、シェルへのインジェクションは起こりません。シェルが先に展開してしまわないよう、必ずシングルクォートで囲んでください。

**対象外の範囲**

対応しているのは CVSS v4.0 だけです。**Lagune** はすべての検出事項を v4.0 で評価するため、v2.0、v3.0、v3.1 のベクトルはスコアを算出せずに拒否します。

**ヒント**

plan フェーズの検証では、CVSS の各行に対してこれと同じ計算をやり直すため、ベクトルと食い違ったスコアは計画が承認される前に見つかります。

## よくある質問

### Lagune は CVSS スコアをどのように算出していますか？

cvss フックは FIRST による CVSS v4.0 のリファレンス計算ツールに準拠しているため、ベクトルのスコアは FIRST のサイトで算出した結果と完全に一致します。

### CVSS v3.1 のベクトルのスコアも算出できますか？

いいえ。Lagune はすべての検出事項を CVSS v4.0 で評価しており、フックはそれ以外のバージョンについてはスコアを算出せず、拒否します。

### --explain フラグは何をするものですか？

各メトリクスをわかりやすい言葉で読み解き、全体のスコアと並べて Base スコアを表示します。これで、ベクトルが何を表しているのか、プロジェクトの状況によってスコアがどう変わったのかを誰でも確認できます。

---

# infra フック：IaC の設定ミスを検出する

> コマンドラインから、Terraform、Dockerfile、GitHub Actions の設定ミスをスキャンしたり、1 つのコードスニペットを判定したりできます。

正規 URL: https://lagune.ai/ja-JP/docs/hooks/infra
言語: ja-JP
原文: https://lagune.ai/docs/hooks/infra
最終更新日: 2026-11-03

`infra` フックは、インターネット全体に開放されたネットワーク、ワイルドカードの権限、マニフェスト内のシークレット、root で動くコンテナ、CI のシェルに渡る信頼できない値といった、ファイルだけで判定できる **IaC（Infrastructure as Code）の設定ミス**を指摘します。読み取るのは IaC ファイル（`.tf`/`.tf.json`/`.hcl`、`Dockerfile*`、`.github/workflows/**`）だけです。また、[`infra` 専門知識](https://lagune.ai/ja-JP/docs/catalog) を支える決定論的なエンジンでもあり、**scan** モードまたは **check** モードで動作します。

## 実行方法

**コードベースをスキャン**

```bash
npx lagune read infra                   # scans every IaC file
npx lagune read infra --dir infra       # scans a directory
npx lagune read infra --file Dockerfile # scans a single file
```

**コードスニペットをチェック**

コードスニペットを `--pattern` で、その種類を `--kind`（`terraform`、`dockerfile`、`github-actions` のいずれか）で渡します。

```bash
npx lagune read infra --kind terraform  --pattern 'actions = ["*"]' # => iam-wildcard
npx lagune read infra --kind dockerfile --pattern 'FROM node:20'    # => mutable-tag
```

スキャンは最大 2 つのセクションを出力します。**Infrastructure risks found** は判定可能な不備（機密性の高いポートへの `0.0.0.0/0` からのインバウンド許可、ワイルドカードを使った IAM ステートメント、マニフェスト内のシークレット、`encrypted = false`、バージョンが固定されていない git モジュール、明示的に root で動くイメージ、`curl | sh`、CI のスクリプトインジェクション、`permissions: write-all`）の一覧で、フックは 0 以外の終了コードで終了します。**Infrastructure hardening advisories** は終了コードを変えません（中身が変わりうるベースイメージのタグ、タグで固定したアクション）。何も見つからなければ `no infrastructure risks found` と出力します。

## 判定の読み方

check モードは、一致したタグのうち最も深刻度の高いもの（例：`public-ingress`、`iam-wildcard`、`root-user`、`curl-pipe`、`script-injection`、`write-all`）、推奨事項のタグ（`mutable-tag`、`unpinned-action`）、または `safe` を出力します。0 以外の終了コードで終了するのは、検出事項レベルの深刻度のタグだけです。

### CLI オプション

| オプション  | 値                                              | 説明                                                                                        |
| ----------- | ----------------------------------------------- | ------------------------------------------------------------------------------------------- |
| `--pattern` | コードスニペット                                | 1 つのコードスニペットをチェックする。`--kind` が必要。繰り返し指定で複数をチェックできる。 |
| `--kind`    | `terraform` \| `dockerfile` \| `github-actions` | コードスニペットをどの種類として判定するか。                                                |
| `--dir`     | ディレクトリ                                    | スキャン対象をディレクトリに絞る。繰り返し指定でき、`--file` と併用できる。                 |
| `--file`    | ファイル                                        | スキャン対象を 1 つのファイルに絞る。繰り返し指定でき、`--dir` と併用できる。               |

オプションを指定しなければ、プロジェクト内のすべての IaC ファイルをスキャンします。`--pattern` は `--dir` や `--file` とは併用できません。

**ヒント**

フックが捉えるのは明白で判定可能なケースで、暗号化の設定漏れ、`pull_request_target` による露出、適切な IAM の範囲といった判断は、引き続き [`infra` 専門知識](https://lagune.ai/ja-JP/docs/catalog) が担います。

## よくある質問

### infra フックはどのインフラ関連ファイルを読み取りますか？

Terraform/HCL（.tf、.tf.json、.hcl）、Dockerfile、そして .github/ 配下にある GitHub Actions のワークフローとアクションの YAML です。ソースコード向けのスキャナーはこれらのファイルを読み飛ばしますが、このフックは読み取ります。

---

# interpreter フック：動的コード実行のシンクを指摘する

> コマンドラインから、さまざまな言語の動的コード実行のシンクをコードベース全体でスキャンしたり、1 つのコードスニペットを判定したりできます。

正規 URL: https://lagune.ai/ja-JP/docs/hooks/interpreter
言語: ja-JP
原文: https://lagune.ai/docs/hooks/interpreter
最終更新日: 2026-11-03

`interpreter` フックは、**動的コード実行のシンク**を指摘します。データを実行可能なコードに変えたり、シェルに渡したりする構文のことで、`eval` からネイティブのデシリアライズまでが含まれます。言語を識別して動作し、各ファイルをその言語のルールで読み取ります。また、[`interpreter` 専門知識](https://lagune.ai/ja-JP/docs/catalog) を支える決定論的なエンジンでもあり、**scan** モードまたは **check** モードで自分で実行することもできます。

## 実行方法

**コードベースをスキャン**

```bash
npx lagune read interpreter               # scans the whole project
npx lagune read interpreter --dir src     # scans a directory
npx lagune read interpreter --file app.py # scans a single file
```

**コードスニペットをチェック**

```bash
npx lagune read interpreter --lang javascript --pattern 'eval(x)'   # => careful
npx lagune read interpreter --lang python --pattern 'json.loads(x)' # => safe
```

こうしたシンクは正当な用途にも悪用にも使えるもので、攻撃者の影響を受けた入力がそこに届くかどうかは、静的スキャンでは判定できません。そのため、一致したものはすべて**確認すべき注意点**であり、確定した検出事項ではありません。スキャンは、ファイルごとにまとめた **Dynamic-execution sinks to review** セクションを 1 つだけ出力します。何も見つからなければ `no dynamic-execution sinks found` と出力します。

**指摘されたコードは読むだけにして、決して実行しない！**

各シンクは**静的に**検討し、信頼できない入力が届くかどうかをたどってください。動作を"試す"ために、指摘されたコードや、そのコードが取り込むリモートのコード、実行時に取得されるコードを実行したり `eval` したりしてはいけません。

## 判定の読み方

| 判定      | 意味                                                                                         |
| --------- | -------------------------------------------------------------------------------------------- |
| `careful` | コードスニペットに、その言語の動的実行のシンクが含まれている。実行せず、読んで確認すること。 |
| `safe`    | 指定した言語の動的実行のシンクは見つからなかった。                                           |

### CLI オプション

| オプション  | 値               | 説明                                                                                                             |
| ----------- | ---------------- | ---------------------------------------------------------------------------------------------------------------- |
| `--pattern` | コードスニペット | 1 つのコードスニペットをチェックする。繰り返し指定すると複数をチェックし、1 行に 1 つずつ判定を出力する。        |
| `--lang`    | 言語             | `--pattern` を使うときは必須：javascript、python、php、ruby、java、kotlin、go、rust、c、cpp、csharp のいずれか。 |
| `--dir`     | ディレクトリ     | スキャン対象をディレクトリに絞る。繰り返し指定でき、`--file` と併用できる。                                      |
| `--file`    | ファイル         | スキャン対象を 1 つのファイルに絞る。繰り返し指定でき、`--dir` と併用できる。                                    |

オプションを指定しなければ、プロジェクト全体をスキャンします。`--pattern` には `--lang` が必要で、`--dir` や `--file` とは併用できません。

### 対応言語

スキャンはファイル拡張子をもとに次の言語を読み取り、それぞれの言語に固有の動的実行のシンクと照らし合わせてチェックします。

| #   | 言語                        | 拡張子                                                                                                       | 指摘するシンク                                                                                                                                                                                                       |
| --- | --------------------------- | ------------------------------------------------------------------------------------------------------------ | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| 1   | **JavaScript / TypeScript** | `.js`、`.jsx`、`.mjs`、`.cjs`、`.ts`、`.tsx`、`.mts`、`.cts`、`.astro`、`.vue`、`.svelte`、`.marko`、`.riot` | `eval()`、Function コンストラクター、文字列を本体とする `setTimeout`/`setInterval`、`vm` モジュール、`child_process` の exec、動的な `require()`、動的な `import()`                                                  |
| 2   | **Python**                  | `.py`、`.pyi`                                                                                                | `eval`/`exec`、`__import__()`、`os.system`/`os.popen`、`subprocess` の `shell=True`、`pickle.load`/`loads`、`yaml.load`（安全でない使い方）                                                                          |
| 3   | **Ruby**                    | `.rb`                                                                                                        | eval 系（`instance_eval`/`class_eval`/`module_eval`/`eval`）、`system`/`exec`、バッククォートまたは `%x`、`Kernel#open` / `IO.popen`/`read`/`binread` / `Open3`、`Process.spawn`、`Marshal.load`                     |
| 4   | **Go**                      | `.go`                                                                                                        | `exec.Command`/`exec.CommandContext`、`plugin.Open`                                                                                                                                                                  |
| 5   | **PHP**                     | `.php`                                                                                                       | `eval()`、文字列を渡した `assert()`、`create_function()`、シェル実行（`system`/`exec`/`shell_exec`/`passthru`/`popen`/`proc_open`）、`call_user_func`/`call_user_func_array`、実行時のパスを使う `include`/`require` |
| 6   | **Rust**                    | `.rs`                                                                                                        | `Command::new`、`process::Command`                                                                                                                                                                                   |
| 7   | **Java**                    | `.java`                                                                                                      | `Runtime.exec`、`ProcessBuilder`、`ScriptEngine`、`ObjectInputStream.readObject`                                                                                                                                     |
| 8   | **Kotlin**                  | `.kt`、`.kts`                                                                                                | JVM のシンク：`Runtime.exec`、`ProcessBuilder`、`ScriptEngine`、`ObjectInputStream.readObject`                                                                                                                       |
| 9   | **C#**                      | `.cs`                                                                                                        | `Process.Start` / `new Process`、`BinaryFormatter`、`Assembly.Load`                                                                                                                                                  |
| 10  | **C**                       | `.c`、`.h`                                                                                                   | `system()`、`popen()`、`exec*` 系（`execl`、`execve`、`execvp`、…）                                                                                                                                                  |
| 11  | **C++**                     | `.cc`、`.cpp`、`.cxx`、`.hpp`、`.hh`、`.hxx`                                                                 | `system()`、`popen()`、`exec*` 系（`execl`、`execve`、`execvp`、…）                                                                                                                                                  |

**ベストエフォートであり、網羅的ではない**

ソースコードをテキストとして読み取るため、実行時に組み立てられたシンクや、エイリアスの陰に隠れたもの、認識できない書き方のものは見逃すことがあります。この表は完全な一覧ではなく、確かな出発点として扱ってください。

**ヒント**

フックが保証するのは最低ライン（こうしたシンクが存在すること、そしてその場所）で、信頼できない値が実際にシンクに届くかどうかの判断は、[`interpreter` 専門知識](https://lagune.ai/ja-JP/docs/catalog) が担います。

## よくある質問

### interpreter フックで脆弱性を確定できますか？

いいえ。動的実行のシンクは確認すべき注意点として指摘するだけで、確定した検出事項にはしません。攻撃者の影響を受けた入力がシンクに届くかどうかは、静的スキャンでは判定できないからです。

### interpreter フックはどの言語に対応していますか？

対応言語の表にある言語を、ファイル拡張子をもとに読み取り、それぞれの言語に固有のシンクと照らし合わせてチェックします。それ以外の言語からシンクが報告されることはありません。

---

# jwt フック：アルゴリズムを固定していない JWT 検証を検出する

> コマンドラインから、アルゴリズムを固定していない JWT 検証をコードベース全体でスキャンしたり、1 つの呼び出しを判定したりできます。

正規 URL: https://lagune.ai/ja-JP/docs/hooks/jwt
言語: ja-JP
原文: https://lagune.ai/docs/hooks/jwt
最終更新日: 2026-11-03

`jwt` フックは、**アルゴリズムを固定していない JWT 検証**と、**検証そのものを無効にしている箇所**を指摘します。前者は、検証側がトークン自身の `alg` ヘッダーを信頼してしまうアルゴリズム混同の穴です。**言語を識別**して動作し、各ファイルをそのファイルが使う JWT ライブラリに合わせて読み取ります。また、[`federation` 専門知識](https://lagune.ai/ja-JP/docs/catalog) を支える決定論的なエンジンでもあり、**scan** モードまたは **check** モードで自分で実行することもできます。

## 実行方法

**コードベースをスキャン**

```bash
npx lagune read jwt                # scans the whole project
npx lagune read jwt --dir src      # scans a directory
npx lagune read jwt --file auth.ts # scans a single file
```

**呼び出しをチェック**

```bash
npx lagune read jwt --lang javascript --pattern 'jwt.verify(token, secret)'                         # => unpinned
npx lagune read jwt --lang python --pattern 'jwt.decode(t, k, options={"verify_signature": False})' # => unpinned
npx lagune read jwt --lang python --pattern 'jwt.decode(t, k, algorithms=["HS256"])'                # => safe
```

**Unpinned JWT verification found** の下に並ぶ各行は、`algorithms` の許可リストを設定していない（ライブラリが必要とする場合）、安全でない許可リストを受け入れている（`none`、または非対称アルゴリズムと HMAC の混在）、あるいは署名の検証を完全に無効にしているために、トークン自身の `alg` を信頼してしまう検証呼び出しです。これは確定したリスクの露出なので、フックは 0 以外の終了コードで終了します。何も見つからなければ `no unpinned JWT verification found` と出力します。

## 判定の読み方

| 判定       | 意味                                                                                                             |
| ---------- | ---------------------------------------------------------------------------------------------------------------- |
| `unpinned` | アルゴリズムの許可リストがない（必要な場合）、許可リストが安全でない、または検証が無効になっている検証呼び出し。 |
| `safe`     | 適切なアルゴリズムの許可リストで固定している、またはライブラリが暗黙的に固定している検証呼び出し。               |
| `invalid`  | 判定できる検証呼び出しがコードスニペットに見当たらない。                                                         |

### CLI オプション

| オプション  | 値               | 説明                                                                                                     |
| ----------- | ---------------- | -------------------------------------------------------------------------------------------------------- |
| `--pattern` | コードスニペット | 1 つの呼び出しをチェックする。繰り返し指定すると複数をチェックし、1 行に 1 つずつ判定を出力する。        |
| `--lang`    | 言語             | `--pattern` を使うときは必須：javascript、python、go、java、kotlin、php、ruby、rust、csharp のいずれか。 |
| `--dir`     | ディレクトリ     | スキャン対象をディレクトリに絞る。繰り返し指定でき、`--file` と併用できる。                              |
| `--file`    | ファイル         | スキャン対象を 1 つのファイルに絞る。繰り返し指定でき、`--dir` と併用できる。                            |

オプションを指定しなければ、プロジェクト全体をスキャンします。`--pattern` には `--lang` が必要で、`--dir` や `--file` とは併用できません。

### 対応言語

スキャンはファイル拡張子をもとに、次のライブラリを読み取ります。ライブラリによってはアルゴリズムを暗黙的に固定する（明示的なリストがなくても安全な）ため、"許可リストなし ⇒ unpinned" というルールは、明示的なリストを前提とするライブラリにだけ適用されます。そのため、正しく設定された呼び出しが指摘されることはありません。

| 言語                        | ライブラリ              | 許可リストなしを unpinned として指摘するか                               | 常に指摘するもの                                |
| --------------------------- | ----------------------- | ------------------------------------------------------------------------ | ----------------------------------------------- |
| **JavaScript / TypeScript** | jsonwebtoken、jose      | はい                                                                     | `none`、非対称アルゴリズムと HMAC の混在        |
| **Python**                  | PyJWT、python-jose      | はい（PyJWT は指定が必須、python-jose はデフォルトが `algorithms=None`） | `none`、`verify_signature: False`               |
| **Go**                      | golang-jwt              | はい（`WithValidMethods` がない場合）                                    | `none`、`ParseUnverified`                       |
| **Ruby**                    | ruby-jwt                | はい                                                                     | `none`、`verify = false`                        |
| **Java / Kotlin**           | jjwt、nimbus            | いいえ（鍵から導出）                                                     | `none`、署名なし/`unsecured` のパーサー         |
| **PHP**                     | firebase/php-jwt        | いいえ（`Key` がアルゴリズムを保持）                                     | `none`                                          |
| **Rust**                    | jsonwebtoken            | いいえ（`Validation` が指定を必須とする）                                | `none`、`insecure_disable_signature_validation` |
| **C#**                      | Microsoft.IdentityModel | いいえ（パラメーターが複数行にまたがる）                                 | `none`、`RequireSignedTokens = false`           |

**ヒント**

フックが判定するのはアルゴリズムの固定だけで、クレーム、鍵、フローのチェックといった判断は、引き続き [`federation` 専門知識](https://lagune.ai/ja-JP/docs/catalog) が担います。

## よくある質問

### JWT のアルゴリズム混同とは何ですか？

トークンのヘッダーからアルゴリズムを読み取る検証処理では、攻撃者が RS256 を HS256 にすり替え、公開鍵で署名できてしまいます。適切なアルゴリズムの許可リストをコードで固定すれば防げます。jwt フックは、許可リストを設定していない、または安全でない許可リストを使っている検証呼び出しを指摘します。

---

# network フック：URL の SSRF リスクを判定する

> コマンドラインから直接、1 つまたは複数のリクエスト先の SSRF リスクを判定できます。

正規 URL: https://lagune.ai/ja-JP/docs/hooks/network
言語: ja-JP
原文: https://lagune.ai/docs/hooks/network
最終更新日: 2026-11-03

`network` フックは、サーバー側のリクエスト先が **SSRF**（内部サービス、クラウドのメタデータ、プライベートなホストに向けられうるリクエスト）に対して安全かどうかを判定します。[`network` 専門知識](https://lagune.ai/ja-JP/docs/catalog) を支える決定論的なエンジンで、自分で実行することもできます。

## 実行方法

各リクエスト先を `--url` で渡します。フックはリクエスト先ごとに 1 語を出力します。その意味は下の表のとおりです。

**1 つのリクエスト先**

```bash
npx lagune read network --url 'http://example.com/'
# => safe

npx lagune read network --url 'http://0x7f000001/'
# => private-target
```

**複数のリクエスト先**

`--url` を繰り返し指定すると、許可リストや拒否リスト全体を 1 回の呼び出しで判定でき、指定した順に 1 行に 1 つずつ判定を出力します。

```bash
npx lagune read network \
  --url 'http://example.com/' \
  --url 'http://[::1]/' \
  --url 'http://allowed.com@evil.example/'
# => safe
# => private-target
# => parser-divergent
```

ホストはネットワークと同じ方法で解釈するため、内部アドレスをエンコードした形式もすり抜けられません：16 進数、8 進数、ドットなしの 10 進数、省略形、IPv6、IPv4 射影アドレスは、どれも `private-target` と判定されます。また、ずさんな検証処理と実際にリクエストを送る処理とで読み取るホストが食い違う場合、判定は `parser-divergent` になります。

## 判定の読み方

| 判定               | 意味                                                                                                         |
| ------------------ | ------------------------------------------------------------------------------------------------------------ |
| `safe`             | リクエスト先が公開ホストに接続し、ずさんな検証処理でも同じホストとして読み取られる。                         |
| `private-target`   | ホストがプライベート、ループバック、リンクローカル、未指定、またはクラウドメタデータのアドレスに解決される。 |
| `parser-divergent` | ずさんなテキスト検証処理が、リクエストを送る処理の実際の接続先とは異なるホストを読み取る。                   |
| `invalid url`      | 文字列を URL として解析できず、リクエストする対象がない。                                                    |

許可を意味するのは `safe` だけです。`private-target`、`parser-divergent`、`invalid url` はいずれもブロックとして扱ってください。

### CLI オプション

| オプション | 値               | 説明                                                                                                  |
| ---------- | ---------------- | ----------------------------------------------------------------------------------------------------- |
| `--url`    | URL またはホスト | 1 つのリクエスト先をチェックする。繰り返し指定すると複数をチェックし、1 行に 1 つずつ判定を出力する。 |

`--url` は少なくとも 1 つ必要です。リクエスト先を位置引数として単独で渡すことはないため、フラグと取り違えられることはありません。

**フラグの値として渡す理由**

各リクエスト先はフラグの値として渡され、コマンドに埋め込まれることはありません。引用符やバッククォートを含む値も無害なままで、シェルへのインジェクションは起こりません。シェルが先に展開してしまわないよう、必ずシングルクォートで囲んでください。

**対象外の範囲**

このフックは純粋関数で、DNS の名前解決を一切行わないため、実行時に生じる 2 つの抜け穴は対象外です：**DNS リバインディング**（チェック時には公開アドレスに、リクエスト時には内部アドレスに解決される名前）と、**リダイレクトチェーン**（最初のホップはチェックを通過し、その後で内部へリダイレクトされるもの）です。これらは、名前解決を 1 回だけ行って検証済みのアドレスに接続し、リダイレクトを拒否することで塞いでください。予約済みのループバック名（`localhost` と `.localhost` 系）は名前解決をせずに内部として扱いますが、それ以外の DNS 名はすべて `safe` と判定されます。内部に解決されると断定するには名前解決が必要になるためです。こうした名前は許可リストで守るもので、このチェッカーが検証するのもその許可リストです。

**ヒント**

これは、リクエスト先のフィルターが有効であることを証明するために [`network` 専門知識](https://lagune.ai/ja-JP/docs/catalog) が実行するチェックと同じものです。

## よくある質問

### URL の SSRF リスクをテストするにはどうすればよいですか？

network フックを実行します。リクエスト先を判定し、safe、private-target、parser-divergent、invalid url のいずれかを返します。許可を意味するのは safe だけです。

### parser-divergent な URL とは何ですか？

パーサーによって解釈が異なる URL のことで、SSRF 対策を回避する典型的な手口です。network フックはこれを許可せず、指摘します。

---

# regex フック：ReDoS パターンを検出する

> コマンドラインから、ReDoS を起こしやすい正規表現をコードベース全体でスキャンしたり、1 つのパターンを判定したりできます。

正規 URL: https://lagune.ai/ja-JP/docs/hooks/regex
言語: ja-JP
原文: https://lagune.ai/docs/hooks/regex
最終更新日: 2026-11-03

`regex` フックは、[`regex` 専門知識](https://lagune.ai/ja-JP/docs/catalog) が実行する、正規表現の安全性を判定する決定論的なエンジンで、自分で実行することもできます。1 つのコマンドで 2 つのモードが使えます：**scan** モードはコードベースをスキャンして、**ReDoS** を起こしやすいパターンや実行時に組み立てられるパターンを探し、**check** モードは渡された 1 つのパターンを判定します。

## コードベースをスキャンする

フラグを付けなければ、プロジェクト全体をスキャンします。`--dir` はスキャン対象をディレクトリに、`--file` は 1 つのファイルに絞ります。どちらも繰り返し指定でき、組み合わせると 1 つのレポートにまとまります。複数の対象に含まれるファイルも、表示されるのは 1 回だけです。

**プロジェクト全体**

```bash
npx lagune read regex
```

**ディレクトリ**

```bash
npx lagune read regex --dir src/services
```

**1 つのファイル**

```bash
npx lagune read regex --file bin/import.pl
```

**複数の対象**

```bash
npx lagune read regex --dir core --dir workers --file Sources/App/Router.swift
```

**上限を指定**

`--limit` はスキャンでの ReDoS のしきい値（デフォルトは 25）を設定します。check モードで使うのと同じ上限です。値が低いほど厳しく判定します。

```bash
npx lagune read regex --dir src/services --limit 15
```

出力はプレーンテキストで、各セクションの見出しがそのセクションの読み方を示しています。セクションは、検出結果があるときだけ表示されます。

```text
Vulnerable regular expressions found:

cmd/server/main.go
  ([a-z]+)+$ (exponential, search)

Dynamically built regular expressions (review manually by simulating a constructed regex):

app/payments.php
crates/parser/lexer.rs
lib/validate.py

Static regex wrapped in a constructor (use a literal instead):

config/token.rb
```

何も見つからなければ、1 行だけ出力します。

```bash
npx lagune read regex --dir src/clean
# => no unsafe patterns found
```

### セクションの読み方

| セクション                                                                                  | 意味                                                                                                                                                                                                         |
| ------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ |
| `Vulnerable regular expressions found`                                                      | ReDoS を起こしやすいパターン。ファイルごとにまとめて各パターンをその下にインデントして示し、続く括弧内に安全でない理由と、ある場合はスコープとフラグを記載する。どの行も安全でないため、判定は繰り返さない。 |
| `Regular expressions the analysis could not settle (review manually)`                       | 解析が作業量の上限内で結論を出せなかったパターン。表示形式は同じ。                                                                                                                                           |
| `Dynamically built regular expressions (review manually by simulating a constructed regex)` | 変数、連結、文字列補間から正規表現を組み立てているファイル。                                                                                                                                                 |
| `Static regex wrapped in a constructor (use a literal instead)`                             | 正規表現リテラルのほうがシンプルで実行時のコンパイルも省けるのに、正規表現のコンストラクターにただの文字列リテラルを渡しているファイル。                                                                     |

1 つ目のセクションは、セキュリティ上の検出事項です。2 つ目と 3 つ目はそれ自体では検出事項ではなく、静的なチェックでは結論を出せないコードを示しているため、人が読んで確認する必要があります。4 つ目はコードをわかりやすくするためのヒントで、セキュリティ上の検出事項ではありません。

### CLI オプション

| オプション  | 値               | 説明                                                                                                                     |
| ----------- | ---------------- | ------------------------------------------------------------------------------------------------------------------------ |
| `--pattern` | 正規表現のソース | 1 つのパターンをチェックする。繰り返し指定すると複数をチェックし、指定した順に 1 パターンにつき 1 つずつ判定を出力する。 |
| `--flags`   | 正規表現のフラグ | すべての `--pattern` をこのフラグ（`im` など）付きでチェックする。check モードにのみ適用。                               |
| `--dir`     | ディレクトリ     | スキャン対象をディレクトリに絞る。繰り返し指定でき、`--file` と併用できる。                                              |
| `--file`    | ファイル         | スキャン対象を 1 つのファイルに絞る。繰り返し指定でき、`--dir` と併用できる。                                            |
| `--limit`   | 0 以上の整数     | ReDoS の繰り返し回数の上限（デフォルトは 25）を設定する。両方のモードに適用。値が低いほど厳しい。                        |

オプションを指定しなければ、プロジェクト全体をスキャンします。`--pattern` は check モードで、`--dir` や `--file` とは併用できません。

### 対応言語

スキャンはファイル拡張子をもとに次の言語を読み取り、それぞれの言語のルールで扱うため、ある言語のパターンが別の言語のルールでテストされることはありません。それ以外のファイルは、誤ったルールでスキャンせずにスキップします。

| #   | 言語                        | 拡張子                                                                                                       |
| --- | --------------------------- | ------------------------------------------------------------------------------------------------------------ |
| 1   | **JavaScript / TypeScript** | `.js`、`.jsx`、`.mjs`、`.cjs`、`.ts`、`.tsx`、`.mts`、`.cts`、`.astro`、`.vue`、`.svelte`、`.marko`、`.riot` |
| 2   | **Python**                  | `.py`、`.pyi`                                                                                                |
| 3   | **Ruby**                    | `.rb`                                                                                                        |
| 4   | **Go**                      | `.go`                                                                                                        |
| 5   | **PHP**                     | `.php`                                                                                                       |
| 6   | **Rust**                    | `.rs`                                                                                                        |
| 7   | **Java**                    | `.java`                                                                                                      |
| 8   | **C#**                      | `.cs`                                                                                                        |
| 9   | **C**                       | `.c`、`.h`                                                                                                   |
| 10  | **C++**                     | `.cc`、`.cpp`、`.cxx`、`.hpp`、`.hh`、`.hxx`                                                                 |
| 11  | **Kotlin**                  | `.kt`、`.kts`                                                                                                |
| 12  | **Swift**                   | `.swift`                                                                                                     |
| 13  | **Scala**                   | `.scala`、`.sc`                                                                                              |
| 14  | **Dart**                    | `.dart`                                                                                                      |
| 15  | **PowerShell**              | `.ps1`、`.psm1`、`.psd1`                                                                                     |
| 16  | **Elixir**                  | `.ex`、`.exs`                                                                                                |
| 17  | **Objective-C**             | `.m`、`.mm`                                                                                                  |
| 18  | **R**                       | `.r`                                                                                                         |
| 19  | **Julia**                   | `.jl`                                                                                                        |
| 20  | **Clojure**                 | `.clj`、`.cljs`、`.cljc`、`.edn`                                                                             |
| 21  | **Crystal**                 | `.cr`                                                                                                        |
| 22  | **Nim**                     | `.nim`、`.nims`                                                                                              |
| 23  | **V**                       | `.v`                                                                                                         |
| 24  | **D**                       | `.d`                                                                                                         |
| 25  | **Perl**                    | `.pl`、`.pm`                                                                                                 |

**ベストエフォートであり、網羅的ではない**

ソースコードをテキストとして読み取るため、実行時に組み立てられるパターンは判定できず、複数行にまたがるパターンや、エイリアスの陰に隠れたもの、認識できない書き方のものは見逃すことがあります。各セクションは完全な一覧ではなく確かな出発点として扱い、セクションで拾えない部分はコードを読んで確認し続けてください。

## 1 つのパターンをチェックする

パターンのソースを `--pattern` で渡すと判定できます。フックが出力するのは、`safe`、`unsafe`、`undetermined`（解析が結論を出す前に作業量の上限に達した場合）、`invalid regex` のいずれか 1 語です。`--pattern` を繰り返し指定すると、複数を一度に判定し、指定した順に 1 パターンにつき 1 つずつ判定を出力します。

**1 つのパターン**

```bash
npx lagune read regex --pattern '(a+)+$'
# => unsafe

npx lagune read regex --pattern '^[a-z0-9_]{3,20}$'
# => safe
```

**複数のパターン**

```bash
npx lagune read regex --pattern '(a+)+$' --pattern '^[a-z]+$'
# => unsafe
# => safe
```

**フラグを指定**

`--flags` を付けると、その呼び出しに含まれるすべての `--pattern` を、実際に使うフラグ付きでチェックします。フラグによって、パターンが一致する文字が変わるためです。

```bash
npx lagune read regex --pattern '^(?:a|A)+$'
# => safe

npx lagune read regex --pattern '^(?:a|A)+$' --flags 'i'
# => unsafe
```

**上限を指定**

`--limit` は繰り返し回数の上限（デフォルトは 25）を設定し、その呼び出しに含まれるすべての `--pattern` に適用されます。値が低いほど厳しく判定します。

```bash
npx lagune read regex --pattern 'a?a?a?' --limit 2
# => unsafe
```

**引数を引用符で囲む理由**

各パターンはフラグの値として渡され、コマンドに埋め込まれることはありません。引用符やバッククォートを含む値も無害なままで、シェルへのインジェクションは起こりません。シェルが先に展開してしまわないよう、パターンは必ずシングルクォートで囲んでください。

**ヒント**

これは [`regex` 専門知識](https://lagune.ai/ja-JP/docs/catalog) が実行するのと同じエンジンで、scan モードで ReDoS の確認を始め、見つかったパターンを check モードで確かめます。

## よくある質問

### CLI で正規表現の ReDoS をチェックするにはどうすればよいですか？

npx lagune read regex --pattern '<pattern>' を実行します。safe、unsafe、undetermined、invalid regex のいずれかが返ります。

### プロジェクト全体で安全でない正規表現をスキャンするにはどうすればよいですか？

コードベースに対して regex フックを scan モードで実行します。対応している 25 の言語にわたって、ReDoS を起こしやすいパターンを報告します。

---

# secrets フック：ハードコードされたシークレットを検出する

> コマンドラインから、ハードコードされた認証情報をコードベース全体でスキャンできます。

正規 URL: https://lagune.ai/ja-JP/docs/hooks/secrets
言語: ja-JP
原文: https://lagune.ai/docs/hooks/secrets
最終更新日: 2026-11-03

`secrets` フックは、環境から読み込むのではなく、**ソースコードに埋め込まれている認証情報**を指摘します。判断の基準は値の中身ではなく**出どころ**（リテラルか、環境からの読み込みか）なので、プロバイダーごとのプレフィックスを網羅した一覧は必要なく、誤検知もほとんど出ません。[`secrets` 専門知識](https://lagune.ai/ja-JP/docs/catalog) を支える決定論的なエンジンです。

プロバイダー固有の形式のシグネチャ、接続文字列に含まれる認証情報、シークレットを示す名前の識別子に代入されたリテラルは、**言語に依存しません**：同じ文字列はどのファイルでも同じように読み取れます。一方、構文に依存する 2 つのヒューリスティック（ハードコードされたデフォルト値を持つ環境変数の読み込みと、ログのシンクに流れ込むシークレット）は**言語を識別**して動作します。そのため、JavaScript の `console.log` を Rust のファイルで探すことはなく、Python の `os.getenv("X", "default")` も Python 独自の書き方として認識されます。

## 実行方法

```bash
npx lagune read secrets                  # scans the whole project
npx lagune read secrets --dir src        # scans a directory
npx lagune read secrets --file config.ts # scans a single file
```

スキャンは最大 2 つのセクションを出力します。**Hardcoded secrets found** は検出事項の一覧（シークレットを示す名前の環境変数に対するハードコードされたデフォルト値、接続文字列に埋め込まれた認証情報、厳選されたプロバイダー形式に一致する値）で、フックは 0 以外の終了コードで終了します。**Secret handling to review manually** は手がかりの一覧で、シークレットを示す名前の識別子に代入されたただのリテラル（出どころは判定できても、その値が本物のシークレットかどうかは判定できない）と、ログやレスポンスのシンクに流れ込む、シークレットを示す名前の値が並びます。何も見つからなければ `no hardcoded secrets found` と出力します。

### CLI オプション

| オプション | 値           | 説明                                                                          |
| ---------- | ------------ | ----------------------------------------------------------------------------- |
| `--dir`    | ディレクトリ | スキャン対象をディレクトリに絞る。繰り返し指定でき、`--file` と併用できる。   |
| `--file`   | ファイル     | スキャン対象を 1 つのファイルに絞る。繰り返し指定でき、`--dir` と併用できる。 |

オプションを指定しなければ、プロジェクト全体をスキャンします。

### 言語ごとの対応範囲

環境変数のフォールバックに関する検出事項とログのシンクに関する手がかりは、言語ごとの書き方を読み取るため、下の言語だけが対象で、それ以外の言語では何も報告しません。残りの 3 つのシグナルは**すべての**ファイルで動作します。

| シグナル                  | 言語                                                                             |
| ------------------------- | -------------------------------------------------------------------------------- |
| 環境変数のデフォルト値    | JavaScript/TypeScript、Python、Ruby、PHP、Kotlin、Java、Go（`cmp.Or`）、Rust、C# |
| ログ / レスポンスのシンク | JavaScript/TypeScript、Python、Ruby、PHP、Java、Kotlin、Go、Rust、C、C++、C#     |

**これはポリシー上の問題にあたるのか？**

いいえ。シークレットの形式を検出して、それがコミットされたことを警告するのは標準的な防御用ツールの役割で、gitleaks、trufflehog、GitHub push-protection が行っているのと同じ処理です。このフックに含まれるのは検出用のシグネチャ（公開されているトークンの**形式**）だけで、有効なシークレットは一切含まれません。また、データを持ち出すのではなく、監査して説明します。

## よくある質問

### secrets フックはどうやって誤検知を防いでいますか？

値の中身ではなく、出どころを基準に判断します。確度の高い形式（プロバイダーのトークン、環境変数のフォールバック、接続文字列）は検出事項として扱い、0 以外の終了コードで終了します。シークレットを示す名前の識別子に代入されたただのリテラルは、確認が必要な手がかりとして挙げます。同じ識別子でも process.env から読み込んでいれば、一切指摘しません。

---

# Lagune のプロンプト例：Blue Team フローを自動化する

> コピーしてすぐ使える Lagune のプロンプト集です。読み取り専用のスキャン、Blue Team フロー全体の実行、ゼロトラスト監査に加え、特定のコミット、ブランチや PR の差分、実際のインシデントに範囲を絞った検出も紹介します。

正規 URL: https://lagune.ai/ja-JP/docs/examples/prompts
言語: ja-JP
原文: https://lagune.ai/docs/examples/prompts
最終更新日: 2026-11-03

AI エージェントにそのまま貼り付けて使える、コピー用の Lagune のプロンプトです。

## 💧 簡易スキャン

エージェントが自分でコードを読み、見つけた欠陥をすべて修正とともに報告する、読み取り専用のスキャンです。Blue Team フローは実行せず、Lagune の追跡記録にも書き込みません。

**ヒント**

プランモードで、セキュリティ原則（`/lagune-charter`）を定めた状態で使うと、より効果的です。

**🪼 標準**

| 観点               | トレードオフ                                                    | レベル              |
| ------------------ | --------------------------------------------------------------- | ------------------- |
| **作業量**         | 1 つのエージェントがスキャンして報告。サブエージェントなし。    | 1/5 |
| **所要時間**       | 短い。読み取り専用で 1 回走査するだけで、何も適用しない。       | 2/5 |
| **トークン使用量** | 中程度で、共有。スキャン全体が 1 つのコンテキストで実行される。 | 2/5 |

```md
/lagune あなたは防御的セキュリティに深い知見を持つサイバーセキュリティ研究者で、Lagune を使って知識と精度を高めています。

ワークスペースを自分でスキャンし、見つけた欠陥ごとに具体的な修正を示してください。これは Blue Team フローではなく単独のスキャンです。detect、plan、harden、verify は実行せず、Lagune の追跡記録には何も書き込まないでください。

最後に、見つけた欠陥をすべて、それぞれの深刻度と具体的な修正とともに一覧にしてください。
```

**🐬 マルチエージェント**

| 観点               | トレードオフ                                                                        | レベル              |
| ------------------ | ----------------------------------------------------------------------------------- | ------------------- |
| **作業量**         | ファイルごとに 1 つのサブエージェント。数はコードベースの規模に合わせて調整される。 | 2/5 |
| **所要時間**       | ファイルごとに並列で進め、最後に 1 つの報告にまとめる。読み取り専用のまま。         | 3/5 |
| **トークン使用量** | 多め。ただし分離されている。各サブエージェントが自分のコンテキストでスキャンする。  | 3/5 |

````md
/lagune あなたは Lagune を使うサイバーセキュリティのオーケストレーターです。パスを列挙し、パスごとにサブエージェントを 1 つ起動して、その報告をまとめます（内容はすべてサブエージェントが読みます）。

現在のプロジェクトの規模に応じて、タスクをサブエージェントに委任してください。コードベースが大きいほど多くのサブエージェントをすべて並列で起動し、それぞれに次のプロンプトを渡してください：

```prompt
/lagune あなたは防御的セキュリティに深い知見を持つサイバーセキュリティ研究者で、Lagune を使って知識と精度を高めています。

<path> を自分でスキャンし、見つけた欠陥ごとに具体的な修正を示してください。これは Blue Team フローではなく単独のスキャンです。detect、plan、harden、verify は実行せず、Lagune の追跡記録には何も書き込まないでください。

最後に、<path> の欠陥をすべて、それぞれの深刻度と具体的な修正とともに一覧にしてください。
```

最後に、すべてのサブエージェントの報告を、優先順位を付けた 1 つの欠陥と修正の一覧にまとめてください。
````

**警告**

簡易スキャンは範囲を絞らない広いプロンプト 1 つで行うため、エージェントによっては拒否したり、途中で打ち切ったりしやすくなります。使っているエージェントが応じない場合は、代わりに下の **Blue Team フロー**全体を実行してください。範囲を絞って段階的に進むフェーズのほうが、ブロックされる可能性ははるかに低くなります。

---

## 🌊 Blue Team 監査フローの自動実行

[コマンドのフロー全体](https://lagune.ai/ja-JP/docs/get-started/commands) を、入力のために止まることなく、最初から最後まで実行します。

**🪼 標準**

| 観点               | トレードオフ                                                                              | レベル              |
| ------------------ | ----------------------------------------------------------------------------------------- | ------------------- |
| **作業量**         | コードベースの規模にかかわらず、1 つのエージェントのみ。サブエージェントなし。            | 3/5 |
| **所要時間**       | 中程度。ただし大きなコードベースでは網羅性が下がる。各コマンドを 1 回ずつ順番に実行する。 | 4/5 |
| **トークン使用量** | 少なめ。ただし分離性は低い。すべてのコマンドが同じコンテキストを共有する。                | 4/5 |

```md
次のコマンドを 1 つずつ実行してください：`/lagune-charter`、`/lagune-detect`、`/lagune-plan`、`/lagune-harden`、`/lagune-verify`。

## ループ

`/lagune-verify` が 1 つ以上の修正を不合格と判定した場合は、すべての検出事項が適切に解決されるまで、`/lagune-harden` と `/lagune-verify` を順に繰り返してください。

## 重要

- 途中で止まったり、質問したりしないでください。迷ったときは、すべて "full" モードで実行してください。
```

**🐋 マルチエージェント（ディープスキャン）**

| 観点               | トレードオフ                                                                                           | レベル              |
| ------------------ | ------------------------------------------------------------------------------------------------------ | ------------------- |
| **作業量**         | サブエージェントの数は、コードベースの規模に合わせて調整される。                                       | 5/5 |
| **所要時間**       | 長め。ただし網羅性は高い。複数のサブエージェントを起動し、検出事項の検出、計画、堅牢化を並列で進める。 | 5/5 |
| **トークン使用量** | 多め。ただしより安全。各サブエージェントが、偏りのない独立したコンテキストを持つ。                     | 5/5 |

````md
次のコマンドを、それぞれ 1 つのサブエージェントに、1 つずつ順番に実行させてください（バッククォートは付けず、コマンドだけを渡します）：

サブエージェント 1 のプロンプト：`/lagune-charter`
サブエージェント 2 のプロンプト：`/lagune-detect`
サブエージェント 3 のプロンプト：`/lagune-plan`
サブエージェント 4 のプロンプト：`/lagune-harden`
サブエージェント 5 のプロンプト：`/lagune-verify`

`/lagune-detect`、`/lagune-plan`、`/lagune-harden`、`/lagune-verify` の各コマンドでは、現在のプロジェクトの規模に応じて、タスクをサブエージェントに委任してください。コードベースが大きいほど、多くのサブエージェントを起動します。例：

```prompt
/lagune-detect <path>
```

```prompt
/lagune-plan <finding>
```

```prompt
/lagune-harden <finding>
```

```prompt
/lagune-verify <finding>
```

- 同じコマンドを担当する複数のエージェントは、並列で起動してください。
- すべての `/lagune-detect` サブエージェントが終わったら、次を実行してください：

```prompt
/lagune-detect 同等の検出事項をまとめてください。新しい検出事項を探したり、コードベースを再スキャンしたりはしないでください。
```

## ループ

`/lagune-verify` が 1 つ以上の修正を不合格と判定した場合は、すべての検出事項が適切に解決されるまで、`/lagune-harden` と `/lagune-verify` を順に繰り返してください。

## 重要

- 途中で止まったり、質問したりしないでください。迷ったときは、すべて "full" モードで実行してください。
````

---

## 🪄 範囲を絞った検出

[`/lagune-detect`](https://lagune.ai/ja-JP/docs/commands/detect) を、プロジェクト全体ではなく、その一部に向けて実行します。範囲を普段の言葉で説明すれば（特定のコミット、プルリクエスト、実際に起きた状況）、その範囲にあるセキュリティ上の検出事項だけを洗い出します。

**ヒント**

ここで検出されたものはすべて通常の検出事項なので、そのまま `/lagune-plan`、`/lagune-harden`、`/lagune-verify` に引き継ぎ、それらの項目だけを対象に進められます。

**📌 特定のコミット以降**

新しく積み上がったコミットに、その変更内容だけを対象とした専用のセキュリティチェックを行います。例：

```prompt
/lagune-detect コミット `a1b2c3d` 以降に変更されたものすべてに範囲を絞って検出してください。
```

**🔀 ブランチや PR の差分**

プルリクエストをマージする前に、その差分だけを対象にセキュリティをレビューします。例：

```prompt
/lagune-detect このブランチが `main` に対して加えた変更に範囲を絞って検出してください。
```

**⛑️ インシデントのあと**

何が起きたのかを自分の言葉で説明してください。Lagune はフラグではなく状況そのものを読み取り、的を絞った調査に変えます。例：

```prompt
/lagune-detect 数週間前、うちのサイトでデータ漏洩が起きました。具体的にどう起きたのかはわかっておらず、まだどこかに穴が残っていて、また漏洩するのではないかと心配しています。コードを注意深く確認し、機密データを読み取る、保存する、外部にさらすあらゆる箇所に重点を置いて、データが漏れ出す経路になりうるものをすべて洗い出してください。訓練ではなく、実際のインシデントとして扱ってください。
```

---

## 🚨 ゼロトラスト監査

ワークスペース全体とすべての依存関係を敵対的なものとして扱います。インタープリター、ネットワーク呼び出し、エンコードされたペイロード、スキャナーをすり抜けるために思いもよらない場所に隠されたコードを探し出し、最後に、プロジェクトを安全に使えるかどうかの判定（go/no-go）を下します。

プロンプトは、この監査に必要な専門知識を、プロジェクトのカテゴリにかかわらず直接読み込みます。`/lagune` がカタログから照合するそれ以外の専門知識のために、プロジェクトで **OWASP**、**AI/LLM**、そして技術スタックに対応するカテゴリ（**JavaScript**、**Python** など）を使うようにしてください：

```bash
npx lagune write add --categories owasp ai javascript
```

**危険**

信頼できない提供元のプロジェクトをローカル環境で実行するときは注意してください。悪意のあるコードがシステムに影響を与えないよう、**サンドボックス**（推奨）や **VM** などの隔離された環境を使ってください。

**🪼 標準**

| 観点               | トレードオフ                                                                              | レベル              |
| ------------------ | ----------------------------------------------------------------------------------------- | ------------------- |
| **作業量**         | 1 つのエージェントがワークスペース全体をスキャン。サブエージェントなし。                  | 2/5 |
| **所要時間**       | 中程度。1 つのエージェントがコードと依存関係を順番に調べる。                              | 3/5 |
| **トークン使用量** | 中程度。ただし共有。専門知識、コード、依存関係がすべて 1 つのコンテキストに読み込まれる。 | 3/5 |

```md
/lagune あなたはゼロトラストの防御的セキュリティに深い知見を持つサイバーセキュリティ研究者で、Lagune を使って知識と精度を高めています。

ワークスペース全体を、信頼できない提供元であり、悪意を含みうる範囲として洗い出してください。インタープリター、fetch、base64 などは、どれも潜在的な脅威とみなしてください。

分析は依存関係と間接的な依存関係にも広げてください。プロジェクトは、スキャナーをすり抜けるために、思いもよらない場所に悪意のあるコードを隠そうとすることがあります。

必須の専門知識（`npx lagune read catalog <name>` で 1 つずつ読み込んでください）：

- interpreter
- secrets
- llm
- path

念のため明確にしておくと、洗い出した脆弱性は例外なく、すべて潜在的な脅威として扱ってください。

最後に、このプロジェクトが私にとって安全で、信頼して使えるかどうかの判定を下してください。
```

**🐋 マルチエージェント（ディープスキャン）**

| 観点               | トレードオフ                                                                                       | レベル              |
| ------------------ | -------------------------------------------------------------------------------------------------- | ------------------- |
| **作業量**         | ファイルごとに 1 つのサブエージェント。数はコードベースの規模に合わせて調整される。                | 5/5 |
| **所要時間**       | 長め。ただし網羅性は高い。ファイルを並列でスキャンし、最後に 1 つの判定にまとめる。                | 4/5 |
| **トークン使用量** | 最も多い。ただし最も安全。各サブエージェントが、それぞれ独立したコンテキストで専門知識を読み込む。 | 5/5 |

````md
/lagune あなたは Lagune を使うサイバーセキュリティのオーケストレーターです。ファイルを列挙し、ファイルごとにサブエージェントを 1 つ起動して、報告を作成します（内容はすべてサブエージェントが読みます）。

ファイルごとにサブエージェントを 1 つ、すべて並列で起動し、それぞれに担当ファイルに範囲を絞った次のプロンプトを渡してください：

```prompt
/lagune あなたはゼロトラストの防御的セキュリティに深い知見を持つサイバーセキュリティ研究者で、Lagune を使って知識と精度を高めています。

<file> を、信頼できない提供元であり、悪意を含みうる範囲として扱ってください。インタープリター、fetch、base64 などは、どれも潜在的な脅威とみなしてください。

分析は <file> がインポートしているものすべてに広げ、依存関係と間接的な依存関係も含めてください。悪意のあるコードは、スキャナーをすり抜けるためにそこに隠れていることがあります。

すべてのサブエージェントに必須の専門知識（`npx lagune read catalog <name>` で 1 つずつ読み込んでください）：

- interpreter
- secrets
- llm
- path

念のため明確にしておくと、洗い出した脆弱性は例外なく、すべて潜在的な脅威として扱ってください。

最後に、このプロジェクトが私にとって安全で、信頼して使えるかどうかの判定を下してください。
```

最後に、すべてのサブエージェントの報告を 1 つの最終判定にまとめてください。
````

---

# Security-Driven Hardening：AI 支援開発時代のための規約

> Security-Driven Hardening（SDH）の方法論：AI 支援開発やバイブコーディングで作られたソフトウェアを監査し、堅牢化するための、コンテキストを踏まえた Blue Team の規約。

正規 URL: https://lagune.ai/ja-JP/docs/references/paper
言語: ja-JP
原文: https://lagune.ai/docs/references/paper
最終更新日: 2026-11-03

- **Weslley Araújo**
- **方法論論文、2026 年**

---

## 概要

Security-Driven Hardening（SDH）は、AI エージェントや、セキュリティの専門家ではない人々がソフトウェアを書く機会が増えている時代に向けた、構造化された AI 駆動型かつ防御専用のセキュリティ方法論です。SDH は汎用的なチェックリストを当てはめるのではなく、まずシステムが実際に何をしているか（ログイン、ファイルアップロード、決済、データの露出など）を検出し、そのうえでそのコンテキストに固有のセキュリティ作業を進めます。デフォルトで安全であることを求める原則に従い、全面的に防御を軸に組み立てられ、どのユーザーでも行動に移せるよう平易な言葉で表現されます。

本稿は、SDH が単一のツールではなく、これまで欠けていた規約であると論じます。セキュリティの知識は方法論とオンデマンドの専門知識に宿り、すべてのユーザーが積み上げていけるベースラインとなります。そのため、初心者にも熟練者にも同じフローで応えられます。従来の仕様ファーストのアプローチ `[1]` とは、2 つの特性で一線を画します。SDH は**状態非依存**です：空のディレクトリ、進行中のプロジェクト、単一のプルリクエスト、大規模なレガシーコードベースのいずれにも、どの技術スタックでも適応します。さらに SDH は**クローズ可能**です：解消が検証されたリスクはフロー全体からクローズされるため、その検出事項は静止状態に達し、コードが変わったときにだけ再オープンされます。SDH は、セキュリティの専門家や専門的な Blue Team ツールに取って代わるものではありません。開発者自身の知識を拡張するものであり、開発者がセキュリティを深く理解しているほど、SDH をより的確に主導できます。

**Lagune** はそのリファレンス実装であり、この方法論が構築可能で移植可能であることを証明しています。SDH を、ほかの人々も採用できる規約として提案します。

> **キーワード**
>
> AI 支援開発、ソフトウェアセキュリティ、防御的セキュリティ、仕様駆動開発、セキュリティ強化、エージェント駆動のワークフロー、クローズ可能性、コンテキストを踏まえたセキュリティ、オンデマンドの知識、エージェント非依存のツール

---

## I. 序論：AI 支援開発が生んだセキュリティのギャップ

ソフトウェアをリリースするのは、安全でないパターン（漏えいしたシークレット、欠けている認可チェック、インジェクション可能なクエリ）を確実には見抜けない人々や AI エージェントであることが増えています。これらは特殊なリスクではありません。実際のインシデントの大半を占めるリスクの種類に含まれ、公開されたリファレンス `[6]`、`[7]` で長年文書化されてきました。また最近の研究では、AI が生成したコードの無視できない割合が、まさにこうした欠陥を抱えたままリリースされていると報告されています `[8]`。AI コーディングアシスタントによって開発者でない人々も実際のソフトウェアをリリースできるようになり、この問題は深刻化しましたが、このギャップは特定の利用者層にとどまりません。ほとんどのプロジェクトは、自らが実際に行うことに特化したセキュリティチェックを一度も受けません。早まって "動くからリリースしよう" と判断するたびに、エコシステムはより脆弱になっていきます。

汎用的なセキュリティのアドバイスでは、このギャップは埋まりません。静的なチェックリストはシステムが何をするかに特化していないため、小さなプロジェクトを無関係な項目で埋め尽くす一方で、そのプロジェクトにとって重要なリスクを見逃してしまいます。問題は、世の中にセキュリティの知識が不足していることではありません。ユーザーの目の前にある実際のシステムに適切な知識を当てはめること、そしてそれを、何を尋ねればよいのかわからないかもしれない人のために行うことこそが問題なのです。

SDH はこれに、1 つの反転で応えます。**セキュリティの知識は仕様とオンデマンドの専門知識に宿り、すべてのユーザーが積み上げていけるベースラインとなる**、という反転です。方法論はコンテキストを検出し、そのコンテキストが抱えるリスクをトリアージし、修正を導きます。そのため、開発者にもそうでない人にも同じフローで応えられます。検出事項と推奨事項は平易な言葉で書かれたままなので、読み手の技術的な知識の深さにかかわらず行動に移せます。熟練者はこれに制約されるのではなく、むしろ力を増幅されます。この二面性については `§VI` で詳しく論じます。

> **要点**
>
> **核心となる反転**：セキュリティの知識は仕様とオンデマンドの専門知識に宿り、すべてのユーザーが積み上げていけるベースラインとなります。方法論はシステムが何をしているかを把握してセキュリティ作業をそれに合わせ、ユーザーがすでに持っている知識を拡張します。

ある開発者が AI アシスタントに "自分のアプリでは、ユーザーがプロフィール画像をアップロードできる" と伝えたとします。セキュリティチェックがなければ、アシスタントは動作するコードを生成しますが、そのコードはクライアントが送ってくるもの（申告されたファイルの種類、ファイル名、サイズ）を何でも黙って信頼してしまいます。アップロード機能はそのままリリースされ、画像を装ったファイルがコードを含んでいたり、細工された名前が保存先のパスから抜け出したり、巨大なファイルがサーバーのリソースを使い果たしたりする可能性が生まれます。デモではこうした問題が一切見えないため、そのままリリースされてしまいます。

同じコードでも、SDH を通すと話が変わります。SDH は、システムが外部からファイルを受け付けていることを検出し（検出）、それをアップロードにともなうリスクとしてトリアージし（トリアージ）、実際のファイルの種類とサイズの確認、保存時の名前の変更、コードが実行されない場所への保存を提案し（修復）、そのうえで結果を読み取って、各対策が実際に有効であることを確認します（検証）。開発者は "無制限のファイルアップロード" という言葉を知っている必要がありませんでした。方法論が代わりに補ったのです。

本稿の貢献は次のとおりです。

- 特定の実装に依存しない、方法論としての SDH の厳密な定義と、その設計原則（`§III`）。
- 職務分離そのものが貢献となる、5 フェーズの防御ライフサイクル：検出は何も創作せず、計画は決してコードを読まず、コードを変更するのは 1 つのフェーズだけで、検証は判定を決して甘くしません（`§IV`）。
- 方法論上の立場としての**クローズ可能性**：個々の検出事項には、終わりのないループではなく最終状態があります（`§V`）。
- **開発者の知識を拡張する**という二面性：初心者を守り、熟練者の力を増幅する 1 つのフロー（`§VI`）。
- **呼び出せない専門知識とオンデマンドプロンプト**：プロジェクトのコンテキストが必要とするときにだけエージェントが読み込み、デフォルトでは決して読み込まない、焦点を絞ったセキュリティの知識（`§VII`）。
- **状態非依存性**と**非強制的な適応性**：SDH はどのような開発状態にも適合し、固定の範囲を押し付けるのではなく状況に適応します（`§VIII`）。
- **予防モード**：通常の作業を構築している最中にも同じ防御を働かせることで、コードは出来上がった時点でデフォルトで安全になり、フェーズが修正すべきことも少なくなります（`§IX`）。
- SDH がそこから生まれ、やがて分かれていった系譜である Spec-Driven Development との、1 節を割いた比較（`§X`）。
- 方法論がリファクタリングを経ても崩れず、特定のエージェントに依存しないようにするためのエンジニアリング上の規律：名前による識別の追跡（`§XI`）と、エージェント非依存の基盤（`§XII`）。

---

## II. 背景と関連研究

SDH は先行研究の上に成り立っています。仕様ファーストでエージェント駆動の開発 `[1]`、`[2]`、`[3]` から、実績のある構造を受け継いでいます。テンプレート、エージェントが読み込むスラッシュコマンド、規範となる文書、そして各フェーズを実行するエージェントです。SDH はこの構造を、防御を目的として再実装しています。この系譜は意図的なもので、SDH の作業原則の 1 つがそれを直接言い表しています。実績のある構造からワークフローを組み立て、それをセキュリティのために位置づけ直す、という原則です。

SDH は、汎用的な推奨事項を並べた静的なチェックリストではありません。チェックリストはセキュリティ全般については多くを知っていても、目の前のプロジェクトについては何も知りません。SDH はこの重点を逆転させます。最初の労力を検出、つまりシステムが何をしているかを知ることに注ぎ、そのあとで初めて、検出によって関連性が明らかになった知識を手に取ります。

SDH は、セキュリティ担当者や専門的な Blue Team ツールの代わりでもありません。開発者の知識を拡張するものです（`§VI`）。専任のセキュリティ部門を持つチームは、それを維持すべきです。SDH はそうしたチームには構造化された基盤を提供し、そうした部門を持たないチームには根拠のあるベースラインを提供します。

SDH は、決定論的なセキュリティスキャナー（静的解析、リンター）`[4]`、`[5]` とも共存します。これらのツールに価値があるのは、まさに決定論的で再現性があるからです。SDH の大部分はエージェントの推論に基づいており、厳密な決定性と引き換えにコンテキスト認識を得ています。方法論はその点を取り繕いません。決定性が重要な場面では、推論の中に決定論的なエンジンを組み込みます（`§VII`）。入力を確認する価値があるかどうかはエージェントが判断し、その入力が危険かどうかは決定論的なプログラムが判断します。

最も直接的な先行事例は Spec-Driven Development（SDD）です。これは、実行可能な仕様から構築を前へ進める、仕様ファーストの方法論の一群です。本稿では SDD を 1 つの類型として扱います。実務者向けの方法論として最も明確に述べたものが Piskala の報告 `[1]` であり、最もよく知られたエージェント駆動のツールキットが GitHub の Spec Kit `[2]`、同じ系統の 2 つ目のツールが OpenSpec `[3]` です。これらが、`§X` における比較の基準となる文献です。

---

## III. SDH：定義と設計原則

**Security-Driven Hardening** は、場当たり的な修正ではなく、エージェントが実行する仕様から作業を進めることで、コードベースをより安全なものに変える、構造化された AI 駆動型のセキュリティ方法論です。この名前は、セキュリティにおける防御側である **Blue Team** に着想を得ています。SDH が扱うのは防御、堅牢化、検証であり、攻撃は決して扱いません。

> **定義**
>
> **Security-Driven Hardening**（SDH）：まずシステムが実際に何をしているかを検出し、次にそのコンテキストに固有のセキュリティ作業を進める、構造化された AI 駆動型かつ防御専用のセキュリティ方法論です。デフォルトで安全であることを求める原則に従い、平易な言葉で表現されます。

SDH は、拘束力のある一連の原則によって定義されます。各原則は 1 つのルールであり、それぞれがユーザーに具体的な保証をもたらします。

| 原則                                               | ルール                                                                                                                                                             | ユーザーへの保証                                                                                                                                                     |
| -------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------ | -------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| デフォルトで安全、平易な言葉で、すべての人に平等に | すべてのデフォルト、メッセージ、修正が最初から安全で、開発者かどうかを問わずどの読み手にも理解できる。特別扱いされるユーザー層はない。                             | 初心者は求めなくても安全なベースラインを受け取り、結果を自分にわかる言葉で読める。                                                                                   |
| 汎用性よりコンテキスト認識                         | すべてのフェーズが detect で検出したコンテキストから出発し、システムが実際に行っていることに基づいて動く。                                                         | 推奨事項はチェックリストではなく、プロジェクトに合ったものになる。セキュリティの知識は仕様とオンデマンドの専門知識に宿り、ユーザーが持ち込む知識を何であれ拡張する。 |
| 硬直性より柔軟性                                   | 原則、要件、推奨事項は出発点である。ユーザーはどれでも言い換え、削除、追加、範囲の縮小ができる。                                                                   | 方法論はプロジェクトとユーザーに合わせて柔軟に変わり、ユーザーが望む以上に厳しくなることはない。柔軟性がデフォルトで安全なベースラインを弱めることは決してない。     |
| 追記のみにせず、照合する                           | 成果物はログではなく生きたドキュメントである。実行のたびにすべてのエントリを再確認し、有効なものは残し、変わったものは書き直し、もう当てはまらないものは削除する。 | 記録は常に現在を反映するため、古いバックログへと劣化することはない。                                                                                                 |
| 防御専用                                           | SDH は監査し、堅牢化し、検証する。攻撃用ツール、悪用目的のエクスプロイト、危害を目的とした検知回避は決して生み出さない。                                           | 方法論を武器に転用することはできない。デュアルユースの内容は、明確に防御的な文脈でのみ扱われる。                                                                     |
| 仕様ファースト、エージェント駆動、セキュリティ志向 | ワークフローはテンプレート、コマンド、規範となるセキュリティ原則、そして各フェーズを実行するエージェントから組み立てられる。                                       | 実績のある開発の構造を転用し、実質的なセキュリティ作業をエージェントが担う。                                                                                         |

**表 1** SDH の設計原則と、それぞれがユーザーにもたらす保証。

これらの原則は飾りではありません。以下のすべてのフェーズが守らなければならない制約であり、`§XV` の議論ではこれらの原則に立ち返って、方法論の限界を明らかにします。

本稿の残りの部分では、名前を付けた 9 つの柱を展開します。これらは読み手が押さえておくべき部分であり、ほかのチームが SDH を実践していると言うために再実装することになる部分でもあります。

| 柱                                       | 提供するもの                                                                                            | 節          |
| ---------------------------------------- | ------------------------------------------------------------------------------------------------------- | ----------- |
| コンテキスト認識による反転               | セキュリティの知識が仕様とオンデマンドの専門知識に宿るため、初心者と熟練者が 1 つのフローを共有できる。 | `§I`、`§VI` |
| 5 フェーズの防御ライフサイクル           | 職務分離：ポリシーの策定、検出、トリアージ、修復、検証が、それぞれ 1 つの役割だけを担う。               | `§IV`       |
| クローズ可能性                           | 検出事項には、終わりのないループではなく最終状態がある。解消した作業はクローズされる。                  | `§V`        |
| 開発者の知識を拡張するという二面性       | 初心者を守り、熟練者の力を増幅する 1 つのフロー。どちらの代わりにもならない。                           | `§VI`       |
| オンデマンドプロンプトと呼び出せない知識 | プロジェクトの実態に応じて関連するセキュリティの知識を読み込み、デフォルトでは読み込まない。            | `§VII`      |
| 状態非依存性と非強制的な適応性           | どの技術スタックのどの開発状態にも適合し、範囲を押し付けるのではなく状況に適応する。                    | `§VIII`     |
| 予防モード                               | 新しい作業の構築中にも同じ防御が働き、コードはデフォルトで安全な状態で出来上がる。                      | `§IX`       |
| 名前による識別の追跡                     | 検出事項はフェーズをまたいでも 1 つの項目のままで、名前の変更でリンクが切れるのは 1 か所だけである。    | `§XI`       |
| エージェント非依存の基盤                 | セキュリティ上の価値は一度だけ書かれ、どのエージェントにも技術スタックにも依存しない。                  | `§XII`      |

**表 2** SDH の 9 つの柱と、それぞれを展開している節。

---

## IV. 5 フェーズの Blue Team フロー

SDH は作業を 5 フェーズの防御ライフサイクルとして構成します（図 1）。各フェーズは防御を軸に組み立てられ、それぞれが前のフェーズの上に積み重なり、実際の Blue Team の活動（ポリシーの策定、検出、トリアージ、修復、検証）に沿っています。

```mermaid
flowchart TB
    charter["1 · charter（ポリシー）<br/>読み取り：プロジェクトと、ユーザーの説明（ある場合）<br/>書き込み：セキュリティ原則<br/>各原則は、防ぐリスクを平易な言葉で伝える"]
    detect["2 · detect（検出）<br/>読み取り：ユーザーのコード<br/>書き込み：detect マップ<br/>創作ではなく検出：コードが裏付けることだけを記録する"]
    plan["3 · plan（トリアージ）<br/>読み取り：detect マップ（コードは決して読まない）<br/>書き込み：防御計画<br/>すべての修正は、detect が実際にマッピングしたものを指す"]
    harden["4 · harden（修復）<br/>読み取り：防御計画と、それが関わるコード<br/>書き込み：コードと堅牢化記録<br/>コードを変更する唯一のフェーズで、修正は 1 つずつ、効果を保てる最小限の変更にとどめる"]
    verify["5 · verify（検証）<br/>読み取り：コードと堅牢化記録<br/>書き込み：クローズに至らない各判定を堅牢化記録へ<br/>コードと記録を静的に突き合わせ、判定を決して甘くしない"]
    charter --> detect --> plan --> harden --> verify
    verify -.->|"差し戻し：harden の作業を再開し、<br/>記録された理由に沿って再適用"| harden
    verify -.->|"クローズ：解消を証明したものを<br/>チェーン全体からクローズし、<br/>履歴に 1 行を残す"| detect
```

**図 1** 5 フェーズのフロー：各フェーズが読み取るもの、書き込むもの、そして要となる不変条件。どちらの戻りも verify が起点です。差し戻された対策は harden を再開させ、解消が証明された検出事項はチェーン全体からクローズされ、履歴に 1 行が残ります。

職務分離こそが貢献です。各フェーズの役割が 1 つだけなので、失敗モードは 1 か所に封じ込められ、読み手は各成果物の記述を信頼できます。

> **要点**
>
> **Applied は検証済みではない**：harden は修正が適用されたことを記録します。verify はコードをその記録と突き合わせて検証し、判定を記録に合わせて甘くすることは決してありません。対策がコードに存在していても、リスクが依然として到達可能なままになっていることがあり、そのときの誠実な判定は "Risk not closed" です。

### charter（ポリシー）

charter は、プロジェクトのセキュリティ原則、つまり後続のすべてのフェーズが守るべきルールを定めます。これは全体を統括するレイヤーであり、プロジェクトのセキュリティ態勢に対するコンパイル時チェックのようなものです。各原則には、明確な名前、コードに対して確認できる譲れないルール、そして修正方法だけでなく防ぐリスクを述べた `Why:` 行があります。charter は常にプロジェクトそのもの（マニフェスト、構造、依存関係）を読み取ります。ユーザーの説明がある場合、それは方向性として扱われ、読み取りはユーザーが挙げた範囲を超えて広がります。説明がなければ、プロジェクトが唯一の情報源です。両者は競合するのではなく足し合わされ、charter が記録するのはコードの現状ではなく、プロジェクトが守るべきポリシーです。開発者でない人でも、これを読んでルールとリスクの両方を理解できるべきです。

### detect（検出）

detect はコードを読み取り、システムが実際に行っていることのうち、セキュリティ上の重みを持つものをマッピングします。指針となるのは "創作ではなく検出" という指示です。コードが裏付けることだけを、後続のフェーズが必要とする証拠とともに記録します。detect は中立です。検出事項をセキュリティ原則に無理に合わせることはしません。リスクをセキュリティ原則のルールと照らし合わせるのは plan フェーズの役割だからです。各検出事項は 3 つの部分からなります。それが何か（平易な言葉による説明）、なぜ重要か（事実だけでなくリスク）、そして証拠（それが存在する関数やルート）です。証拠にはファイルパスを含めません。パスは追跡マップ（`§XI`）にだけ保持されるため、本文に古くなりうるパスが残ることはありません。

### plan（トリアージ）

plan は各検出事項を修正に変えます。修正はリスクの種類で名付けられ（根拠となる場合は、確立されたリファレンスである CWE や OWASP を引用します）、その修正が守る原則と結び付けられます。優先度（緊急、重要、警告、注意）は自由に選べるものではありません。plan は CVSS v4.0 の Base-and-Environmental 方式で各検出事項を評価するため、区分はスコアを平易な言葉で表したものになり、露出の程度と影響の大きさを平易に述べた 1 行の根拠が添えられます。そして 2 回実行しても同じ順序になります。ベクトルは熟練者にとっての正確な拠り所であり、区分とその根拠は、誰もが追える同じ評価です。plan は detect マップだけをもとに作業し、コードは決して読みません。これは限界ではなく意図的な制約です。この制約によって、すべての修正が detect で実際に検出されたものを指すようになります。ある範囲がまだマッピングされていなければ、plan は推測せずに停止し、ユーザーを detect へ戻します。

### harden（修復）

harden はコードを変更する唯一のフェーズなので、慎重に進めます。編集にユーザーの承認が必要かどうかは、エージェントと、そのエージェントが動作する権限モードが決めることなので、harden は独自の確認ステップを追加しません。修正は一度に 1 つずつ、ほかの修正が依存するものを先に、次に優先度の高いものから適用するため、各変更は小さく、レビューしやすく、元に戻しやすいまま保たれます。新しい修正を収めるために既存の対策を弱めることも、セキュリティ原則に反することも決してありません。修正が原則と衝突する場合、harden はそれを適用せずに停止し、衝突を提示します。各ブロックは Applied、Partial、Blocked のいずれかとして記録されます。"Applied はまだ検証済みを意味しない" という点こそ、次のフェーズが扱う問題です。

### verify（検証）

verify は、コードを読み取り、harden が記録した内容と突き合わせることで、適用された各対策を検証します。検証とは、このコードと記録の突き合わせそのものであり、静的に行われます。確認するのは、対策がコードの中に存在し正しいことであって、稼働中のシステムで攻撃を受けても対策が有効であることではありません。実際の攻撃や模擬攻撃を稼働中のシステムに対して実行するような実行時のチェックは、設計上、範囲外です。verify は 3 つの判定のいずれかを返します。Risk closed、Risk not closed、Cannot tell from the code です。verify は独自の成果物を作りません。harden と verify は堅牢化記録を共有し、何を行ったかは harden が、判定とその理由は verify が受け持ち、どちらも相手のフィールドに書き込むことはありません。差し戻された対策は harden がやり直す作業となり、harden は次の実行時に、自分でコードを読んだ結果よりもその判定を優先し、理由に示された不足点に対して正確に再適用します。verify は記録よりもコードを信頼します。記録は、コードが実際に実現している以上のことを主張しうるからです。verify はユーザーのコードに対して読み取り専用であり、記録に合わせて判定を甘くすることは決してありません。対策が存在していても、別の経路からリスクに到達できる場合があり、そのときの誠実な判定は "Risk not closed" です。読み取りの途中で、detect マップがまったく扱っていないセキュリティ上の問題に気づいても、verify はそれに対する判定を創作しません。検出は detect の役割だからです。verify はその問題を提示してユーザーを detect へ戻し、検出事項がフローを迂回せず、同じフローを通って入るようにします。

> **通しの例：ファイルアップロード**。1 つの検出事項で、フローの骨格を端から端まで示します。
>
> - **detect** がこれを見つけます：システムはユーザーからファイルを受け付けており、アップロードハンドラーはクライアントが送る MIME タイプを信頼し、ファイルの実際の種類を確認していません。_なぜ重要か_：画像を装ったファイルに悪意のあるコードが隠れている可能性があります。
> - **plan** が修正を決めます。優先度は**緊急**で、"すべての入力は検証されるまで信頼できない" という原則を守るものです：ファイルの実際の種類とサイズを確認し、保存時に名前を変更し、アップロードされたファイルはコードとして実行できない場所に保存します。
> - **harden** が修正を適用し、ステータスは **Applied** です：ハンドラーはファイルの内容から実際の種類を判別し、サイズ制限を適用し、想定外のものを拒否し、保存時に名前を変更し、コードが実行されない場所に保存するようになりました。
> - **verify** はハンドラーを読み取り、記録と突き合わせて **Risk closed** を返します：コードは記録の主張どおりに動作しています。
>
> 同じ検出事項名が detect マップ、防御計画、堅牢化記録を通じて受け継がれ、verify もその記録に対して同じ名前で作用します。クローズに至らない判定は検出事項のブロックに書き込まれ、解消が証明された検出事項はクローズされます（`§V`）。この共通の名前が、その検出事項の同一性です（`§XI`）。

---

## V. クローズ可能性：検出事項には最終状態がある

ほとんどのセキュリティツールは、増える一方のバックログをユーザーに残します。SDH は異なる立場をとります。**検出事項はクローズ可能であり、終わりのないバックログに居続けるのではなく最終状態を持つ**という立場です（図 2）。これは照合の原則から直接導かれます。

> **定義**
>
> **クローズ可能性**：解消が検証されたリスクはフロー全体からクローズされるため、その検出事項は静止状態に達し、コードが変わったときにだけ再オープンされます。セキュリティへの取り組みそのものは継続しても、個々の検出事項には最終状態があります。

SDH の成果物はログではなく、生きたドキュメントです。フェーズは再実行されるたびに、既存の各エントリを現在の実態と照合し、3 つのうちいずれかを行います。今も有効なものは残し、変わったものは書き直し、もう当てはまらないものは削除します。すでに解決したことがコードから明らかな検出事項は、そのまま削除されます。作業中の記録が反映するのは過去ではなく、現在です。

クローズとは、この同じ照合が結論に達したものです。verify がリスクの解消を検証すると、その検出事項をフロー全体、つまり detect マップ、防御計画、堅牢化記録、追跡マップからクローズします。verify がほかのフェーズの成果物に書き込む唯一のフェーズであるのはこのためです。ループを閉じるのが verify だからです。検出事項がチェーンを離れるとき、クローズによってその内容は短いエントリへと要約され、履歴に記録されます。この履歴は作業中のチェーンの外にあり、再処理されることはありません。ここに、消えることとクローズすることの境界があります。もはや事実でなくなったために照合で削除された検出事項は何も残しませんが、解消が証明された検出事項は履歴に 1 行を残します。クローズされた検出事項はそれ以降、作業中のどの成果物にも現れません。それは想定どおりの状態であり、チェーンが壊れたわけではありません。

```mermaid
stateDiagram-v2
    direction TB
    [*] --> OPEN: detect が検出
    OPEN --> Plan: plan
    Plan --> Harden: harden
    Harden --> Verify: verify
    Verify --> StoodDown: Risk closed
    StoodDown --> SETTLED
    SETTLED --> OPEN: コードの変更で検出事項が再オープン
    Plan: plan
    Harden: harden
    Verify: verify
    StoodDown: STOOD DOWN · 履歴に 1 行
```

**図 2** クローズ可能性の状態遷移。検出事項は OPEN → STOOD DOWN → SETTLED と遷移し、コードが変わったときにだけ再オープンされます。

範囲内のすべてがクローズされると、サイクルは静止状態になります。この静止状態には具体的な形があります。最後の検出事項がクローズされた成果物は丸ごと削除されるため、完全にクローズされたチェーンに残るのは、セキュリティ原則と履歴、つまりポリシーと証明だけです。サイクルが再オープンされるのは、コードが変わったときだけです。方法論は各検出事項に明確な終わりを与えます。これこそ、終わりのないバックログにはできないことです。

---

## VI. 開発者の知識を拡張するという二面性

SDH は人に取って代わるものではなく、専門的な Blue Team ツールに取って代わるものでもありません。SDH は**開発者自身の知識を拡張します**。開発者がセキュリティを深く理解しているほど、フローをより的確に主導でき、裁量も大きくなります。理解が浅い開発者でも安全な結果を受け取れます。自動モードが守ってくれるからです。

`§I` で述べた反転、つまりセキュリティの知識が仕様に宿るということは、両方向に働きます。初心者にとって、それは保護です。仕様のほうから提案するので、何を尋ねればよいかを知る必要がありません。熟練者にとって、それは増幅です。同じ仕様によって、固定のチェックリストと格闘するのではなく、フローを的確に狙いどおりの方向へ向けられます。

すべてのフェーズが、それぞれの動作の中にこの二面性を備えています（図 3）。入力なしで実行すると、フェーズはユーザーに代わって範囲全体を対象に動きます。方向が与えられると、同じフェーズがユーザーの狙ったものだけに正確に絞り込みます。

```mermaid
flowchart TB
    inversion["1 つの反転、2 つの方向：<br/>セキュリティの知識は仕様に宿る"]
    inversion --> auto["自動モード（入力なし）<br/>フェーズが提案し、範囲全体を<br/>対象に動く"]
    inversion --> directed["指示モード（入力あり）<br/>フェーズはユーザーが狙ったものだけに<br/>正確に絞り込む"]
    auto --> novice["初心者は守られる：<br/>何を尋ねればよいか知らなくても<br/>安全な結果を得られる"]
    directed --> expert["熟練者は力を増幅される：<br/>固定のチェックリストではなく、<br/>フローを的確に狙える"]
    novice -.-> phases["同じ 5 つのフェーズが両者に応える：<br/>charter · detect · plan · harden · verify"]
    expert -.-> phases
```

**図 3** 開発者の知識を拡張するという二面性。1 つの反転が 2 種類の利用者に応えます。同じ 5 つのフェーズを通じて、自動モードは初心者を守り、指示モードは熟練者の力を増幅します。

オンデマンドの専門知識（`§VII`）は、この二面性を自らの文面で明示しています。各専門知識はエージェントに対し、その知識は "あなたの判断を拡張する" ものだと伝え、専門知識が提供する範囲を超えて推論を続けるよう求めます。知識は下限であって、上限ではありません。これこそが、本稿の意図するバランスで両方の利用者に応えるものです。開発者コミュニティは実質的な道具を手にし、Blue Team の実務者は、自分の仕事を代わりにこなすふりをしない構造化された基盤を手にします。

---

## VII. 呼び出せない専門知識とオンデマンドプロンプト

これは、この方法論で最も新規性の高いパターンです。SDH は焦点を絞ったセキュリティの知識を、**必要なときにだけ**読み込まれる専門知識として持ち、どれを読み込むかはエージェント自身がプロジェクトのコンテキストとマッチングして決めます。これを**オンデマンドプロンプト**と呼びます。すべてのチェックをデフォルトで実行するのではなく、エージェントが自分のいるプロジェクトの範囲に基づいて、どの知識を有効にするかを選ぶ方法です。専門知識は進化していくものであり、どれもいつでも変更や置き換えがありえます。貢献はこのパターンであって、専門知識そのものではありません。

> **定義**
>
> **オンデマンドプロンプト**：エージェントが、有効にするセキュリティの知識を目の前のプロジェクトの範囲とマッチングして選ぶことです。これにより、すべてのチェックをデフォルトで実行するのではなく、プロジェクトの実態に合った知識が取り込まれます。

> **定義**
>
> **呼び出せない専門知識**：ファイルアップロードやブラウザで動作するコードなど、1 つのコンテキストに焦点を絞った、言語に依存しないセキュリティの知識の単位です。監査と説明を行い、コードを書き換えることも、攻撃用の入力を生成することもありません。コマンドではなく、対象とするコンテキストが範囲内にあるとき、またはプロンプトで名前を指定されたときに読み込まれます。

各専門知識は、扱うリスクに対するより安全な形を示し、それを利用する各フェーズで検出事項にどう対処するかをエージェントに伝えます。検出時にどう判断するか、修復時に修正をどう安全に適用するか、検証時にどう証明するかです。

本質的な特徴は、専門知識が**単独では呼び出せない**ことです。専門知識はコマンドではなく、フローの中ではマッチしたことが読み込みのきっかけになります。検出フェーズはカタログを一度だけ一覧にし、各エントリが扱う内容とプロジェクトのコンテキストをマッチングして、コンテキストが範囲内に存在する専門知識だけを読み込みます。後続のフェーズは一覧を作り直さずにそのマッチ結果を再利用するため、1 回のマッチングがチェーン全体に役立ちます。予防モード（`§IX`）も、これから構築される作業に対して同じマッチングを行います。コンテキストが存在しない専門知識はスキップされますが、スキップにも読み込みと同じ説明責任があります。カタログのすべてのエントリが明示的な判定を受け、適用かスキップかが、コードから読み取った理由とともに示されます。そのため、関係がなさそうだという漠然とした感覚が、存在しないことの代わりになることはありません。適用できるものが 1 つも見つからないのも、正当な結果です。

カタログはデータであり、拡張は知識ファイル 1 つとカタログの 1 行を加えるだけで済み、新しいコマンドは決して必要ありません。組み込みの専門知識は OWASP、特定の言語、AI 連携などのカテゴリに分けられており、プロジェクトが使うカタログには、選んだカテゴリの組み込み専門知識と、プロジェクト独自の専門知識が含まれます。プロジェクトはこの選択をほかの状態と一緒に記録するため、チーム全体が同じカタログに対してマッチングを行います。これはフェーズと同じコンテキスト認識の原則を、知識に適用したものです。すべてのチェックをデフォルトで実行するのではなく、プロジェクトの実態に合った知識が取り込まれます。同じ性質によって、メンテナーだけでなくユーザーもカタログを拡張できます。ユーザーが提供したセキュリティの情報源やトピックは、プロジェクトに属する新しい専門知識へと抽出され、カテゴリにかかわらずそのカタログに加わり、組み込みの専門知識とまったく同じように読み込まれて、同じ名前の組み込み専門知識を置き換えます。専門知識の作成自体も防御専用であり、専門知識が守らせるのと同じ境界に従います。攻撃の解説記事を情報源にしてもかまいませんが、そこから生まれる専門知識は監査と説明を行うだけで、動作するエクスプロイトを出力することは決してありません。こうして、`§I` の反転、つまり知性が仕様に宿るという考え方は、カタログそのものにまで及びます。ユーザーはコードを書かなくても、自分のコンテキストに合わせてカタログを深めていけます。

短い例で、オンデマンドプロンプトを説明します。detect が、ブラウザで動作するコードのフォルダーを読み取るとします。detect はそのコンテキストをカタログでマッチングし、それを扱う専門知識を読み込み、通常の手順を通じてクライアントサイドの検出事項を提示します。この範囲にコンテキストが存在しない専門知識はマッチしないため、読み込まれることはなく、それぞれスキップとして記録されます。どの知識が関連するかを決めたのは、固定の設定ではなく、プロジェクトそのものでした。

決定性は、まさにそれが重要な場所に現れます。専門知識は文章だけでなく、決定論的なチェッカーを持つこともできます。あるリスクの種類に明確な判定手順がある場合、小さなプログラムが与えられた入力に対して固定の判定を返します。たとえば `safe`、`unsafe`、`invalid input` のような少数の語です。リスクの種類の中には、まさにこのように決定論的に判定できるものがあり、その判定手順の背後には先行研究の蓄積があります `[9]`、`[10]`、`[11]`。チェッカーは、エージェントが渡す候補を採点するか、自ら範囲をスキャンして候補を見つけるかのどちらかであり、いずれの場合も判定を返すのはエージェントではなくチェッカーです。十分に汎用的な専門知識は、カタログで必須として指定でき、その場合は常に適用され、チェッカーが範囲全体に対して実行されます。これは、コンテキストのマッチなしに知識が読み込まれる唯一のケースであり、カタログのデータで宣言されるもので、エージェントがその場で決めることはありません。SDH はここで、フロー全体が決定論的であるかのように装うことなく、エージェントの推論を再現可能なものに根ざさせています。

最後に、専門知識は**切り離し可能**です。知識が単独で成り立つため、ユーザーは SDH のフロー全体とは無関係なプロンプトの中で専門知識を直接実行でき、通常の開発と並行してセキュリティを保てます。たとえば決定論的なチェッカーを持つ専門知識なら、通常のコーディング中に生まれる各候補をふるいにかけ、安全なものだけを残せます。この切り離しやすさは SDH が多くの状況に適応できる理由の 1 つであり、それが `§VIII` の主題です。そしてその最も完全な形が予防モード（`§IX`）で、そこでは同じ知識が通常の開発を最初から最後まで守ります。

---

## VIII. 状態非依存性と非強制的な適応性

2 つの特性が、SDH を硬直的な仕様方法論から区別しています。

### 状態非依存性

> **定義**
>
> **状態非依存性**：方法論は開発の状態に依存しません。空のディレクトリ、進行中のプロジェクト、単一のプルリクエスト、大規模なレガシーコードベースのいずれにも、どの技術スタックでも適合します。出発点を、読み取ることによって把握するからです。

プロジェクトがまったく新しいものでも、すでに存在するものでも、すべてのフェーズは同じように動作します。charter は、存在するコードがどのようなものであれ、そこから原則を推定します。detect は、たとえごくわずかでも、そこにあるコードをマッピングします。想定された出発点はありません。

### 非強制的な適応性

> **定義**
>
> **非強制的な適応性**：方法論は、ユーザーが従わなければならない固定の範囲を押し付けるのではなく、状況に適応します。ユーザーが何を言えばよいかわからないときは、自分が呼び出された環境を読み取り、コンテキストを生成し、次に何をするかを形づくる質問を投げかけます。

最もわかりやすい例が charter の提案モードです。SDH はプロジェクトを分析してデフォルトで安全なセキュリティ原則を導き出し、不足している情報が実際に結果を変える場合にだけユーザーに尋ね、そのうえでセキュリティ原則を書き出し、各原則を、それが防ぐリスクとともに平易な言葉で提示します。セキュリティ原則は、承認プロンプトの向こうに閉ざされた契約ではなく、ユーザーが再実行によって作り直していく生きたドキュメントです。そのため、ユーザーが何を尋ねればよいかを知っている必要はまったくありません。

この適応性は、入力の形に対する感度として現れます。同じフェーズが、与えられたものを読み取ってモードを選ぶのです（図 4）。プロンプトに含めたファイル、一覧から選んだ検出事項、気がかりな点、既知の弱点に的を絞ったミッション、総当たりでの全体スキャンの依頼のどれであっても、ユーザーのニーズに応えられます。フローが設計上、非強制的だからです。これらはいずれも、デフォルトで安全なベースラインを弱めるものではありません。柔軟性はベースラインの適用の仕方を形づくるだけで、ベースラインを下げることは決してありません。

```mermaid
flowchart TB
    shape["フェーズは与えられたものの<br/>形を読み取る"]
    shape --> none["入力なし"]
    shape --> paths["1 つ以上のパス"]
    shape --> concern["言葉で説明した懸念"]
    shape --> finding["名前を指定した検出事項"]
    shape --> band["優先度の区分"]
    none --> auto["自動モード：<br/>提案するか、範囲全体を<br/>スキャンする"]
    paths --> focus["それらのファイルや<br/>ディレクトリだけに集中する"]
    concern --> scoped["その 1 つの<br/>懸念に範囲を絞る"]
    finding --> item["その 1 つの<br/>追跡項目に対処する"]
    band --> priority["緊急、重要、警告、注意の<br/>いずれかだけに対処する"]
```

**図 4** 非強制的な適応性。同じフェーズが入力の形を読み取ってモードを選ぶため、範囲は常にユーザーが決めるものであり、押し付けられることはありません。

---

## IX. 普遍的な予防モード：構築中の作業にも同じ防御を

SDH には、補完的なモードが 1 つあります。コードを書いている間も同じ防御を働かせたまま行う、通常の開発です。ユーザーはログインページ、アップロード、エンドポイントといった作業そのものを依頼し、方法論はその構築を進行と同時に守ります。そのため結果は、あとから堅牢化の工程を経るのではなく、出来上がった瞬間からデフォルトで安全です。

> **定義**
>
> **予防モード**：SDH の全体を統括するレイヤーと知識のもとで行う通常の開発です。セキュリティ原則が構築を拘束し、これから作るものに関連する専門知識がオンデマンドで読み込まれ、作業を完了とする前に、結果を、使った防御そのものと突き合わせます。

このモードは、フェーズがすでに備えている各要素を、まだ存在しないコードに向けて再利用します。コンテキストの検出は、コードから意図へと対象を移します。エージェントは、これから構築するものと、その作業がまたぐ境界（ログインには認証情報、セッション、外部からの入力がともなう）を推論し、その推論に対して知識カタログをマッチングします。オンデマンドプロンプト（`§VII`）はここで一般化されます。コンテキストは、既存のコードの中だけでなく、コードの計画の中からも検出できるのです。セキュリティ原則はいつもどおり作業を律し、原則に反する依頼は衝突として提示され、構築されることは決してありません。防御は各部分を書くその瞬間にインラインで適用され、境界で検証し、最初から安全な書き方を選びます。そのため、動作はするが安全でないバージョンが生まれて、あとから修正されるということはありません。

このモードは、verify が始まるのと同じやり方で終わります。作業を完了とする前に、構築者は自らの結果を、使った防御と突き合わせます。対策はリスクの経路の脇ではなく経路上になければならず、完全でなければならず、専門知識が決定論的なチェッカーを持つ場合は、エージェント自身の読み取りよりもチェッカーの判定が優先されます。ここで見つかった不足は同じ作業の一部として埋められます。作業を終えるとは、安全に終えることを意味するからです。

このモードが何をしないかは、何をするかと同じくらい意図的に決められています。依頼されたものだけを構築し、その周囲は何も監査しません。既存のものの監査はフェーズの役割だからです。成果物も書かず、検出事項も追跡しません。検出事項とは既存のものの中で検出されたリスクであり、このモードの目的は、安全でないバージョンがそもそも生まれないようにすることだからです。2 つの方向は互いを補い合います。フェーズはすでに存在するものを解消し（`§V`）、予防モードは新しい作業がそれを再び開いてしまうのを防ぎます。静止状態のチェーンが静止状態のまま保たれるのは、開発が止まったからではなく、静止している間に構築されるものが防御されたうえで構築されるからです。

---

## X. Security-Driven Hardening と Spec-Driven Development の比較

Security-Driven Hardening（SDH）は Spec-Driven Development（SDD）を土台として生まれ、その後大きく分岐しました。構造上の継承は実際にあり、それを認めています。仕様ファースト、エージェント駆動、規範となる文書、そしてエージェントが実行するフェーズ分けされたコマンド群です。SDH はこの構造を意図的に再利用しています。異なるのは、目的、強制力のモデル、前提とする状態、そして終了条件です。本稿では SDD を 1 つの類型として扱い、方法論の標準的な記述として Piskala の報告 `[1]` を、標準的なエージェント向けツールキットとして GitHub の Spec Kit `[2]` を、同じ系統の 2 つ目のツールとして OpenSpec `[3]` を用います。

SDD は仕様を実行可能にすることで、従来の開発をひっくり返します。仕様は実装を導くだけでなく、動作する実装を直接生成します `[1]`。そのフェーズ構成は構築を前へ進めるものです `[2]`（基本原則を定め、何を構築するかを仕様化し、技術スタックを計画し、計画をタスクに分割し、そして実装する）。その規範となる文書は原則をまとめた憲法（constitution）であり、エージェントが終始従わなければならない基礎です。ここに違いの核心があります。SDD の強制力は仕様から構築へと流れ、実装はそれに従うことが期待されます。

SDH は、この契約のほぼすべての軸を反転させます（表 3）。

> **要点**
>
> **核心的な違い**：SDD の強制力は仕様から構築へと流れ、実装はそれに従うことが期待されます。SDH は非強制的で、逆向きに流れます。検出されたシステムのコンテキストから内側へ向かい、すでにあるものを堅牢化します。

| 軸                   | SDD                                                    | SDH                                                                                                                                |
| -------------------- | ------------------------------------------------------ | ---------------------------------------------------------------------------------------------------------------------------------- |
| 目的                 | 機能を提供する。仕様が動作する実装になる。             | 既存のもの、または構築中のものを堅牢化する。すべてのフェーズが防御のために組み立てられている。                                     |
| 強制力のモデル       | 強制的。仕様と憲法が、構築を従うべき範囲に閉じ込める。 | 非強制的。SDH は状況に適応し、ユーザーは言い換え、削除、範囲の縮小ができる。                                                       |
| 状態の前提           | 仕様から前へ進める構築。                               | 状態非依存：空のディレクトリ、進行中のプロジェクト、単一の PR、レガシー。                                                          |
| 終了条件             | 機能が構築されたら終わる。                             | クローズ可能。検出事項は静止状態に達し、コードが変わったときにだけ再オープンされる。                                               |
| 規範となる文書       | エージェントが従わなければならない原則の憲法。         | 防ぐリスクを軸にしたセキュリティ原則（各原則に `Why:` 行がある）。固定の契約ではないと明言している。                               |
| 知識の増やし方       | コマンドを追加する（またはフェーズ構成を拡張する）。   | エージェントがオンデマンドで読み込む、呼び出せない専門知識を追加する。ファイル 1 つとカタログの 1 行で済み、新しいコマンドは不要。 |
| 誰に応えるか         | 機能を前へ進める構築者。                               | 開発者かどうかを問わず、あらゆるユーザーに同じフローで応える。                                                                     |
| コードを変更するもの | 実装フェーズが構築物を生成する。                       | コードを変更するのは harden フェーズだけで、修正は一度に 1 つ。                                                                    |

**表 3** 8 つの軸で見た SDD と SDH。構造は借り物、契約は逆。

系譜に対して公平を期すために述べておくと、SDD は実績のある先行事例であり、SDH が動作する構造は SDD に負っています。この分岐は SDD への批判ではありません。SDD は別の問題（前へ進める構築）をうまく解決しています。SDH は同じ実績ある仕組みを取り入れ、それを防御、適応性、クローズへと向けています。変更提案、タスクリスト、変更ごとの仕様を中心に構成された OpenSpec `[3]` も、このパターンを裏付けています。この系統は仕様から構築を前へ進めますが、SDH は検出したコンテキストからシステムを内側へと堅牢化します。SDH の予防モード（`§IX`）は、SDH が前へ進む構築に寄り添う唯一の場面ですが、そこでも反転した契約は保たれます。予防モードは作業をどう構築するかを律するだけで、何を構築するかを決めることは決してありません。

---

## XI. エンジニアリングの厳密さ：追跡の規律

追記せず照合するという規律（`§V`）には、リファクタリングに耐える土台が必要です。検出事項は、それに関わるすべてのフェーズを通じて 1 つの項目であり続けなければならず、ファイルの名前が変わったり移動したりしてもチェーンが壊れてはなりません。SDH はこれを、**名前による識別**と、**追跡にのみ保持されるパス**によって解決します。

> **定義**
>
> **名前による識別**：検出事項の同一性はその名前であり、すべての成果物でまったく同じ表記で書かれます。本文が持つのは名前であって、パスではありません。ファイルパスは追跡マップにのみ存在するため、名前の変更やファイルの移動でリンクが切れるのは、ちょうど 1 か所だけです。

detect の各検出事項は 1 つの追跡項目です。その同一性は**名前**、つまり節の見出しであり、detect マップ、防御計画、堅牢化記録でまったく同じ表記で書かれます。後続のフェーズは同じ項目に作用するとき、その名前を一字一句そのまま再利用し、verify も同じ名前のもとで堅牢化記録に判定を書き込みます。追跡マップが保持するのは追跡情報だけで、項目ごとに 1 つのエントリがあります：

```json
{ "name": "File uploads", "paths": ["src/routes/upload.ts"] }
```

マップには、本文も注釈も、別個の識別子も、フェーズも記録しません。文章の成果物が言葉を担い、マップは同一性とパスだけを担います。変わりやすいのはファイルパスだけで、それはここにしか存在しません。名前の変更やファイルの移動でリンクが切れるとしても、それはちょうど 1 か所だけであり、2 つの食い違うコピーで起こることは決してありません。

```mermaid
flowchart TB
    detect["detect マップ"] --> name
    plan["防御計画"] --> name
    harden["堅牢化記録<br/>verify はここに判定を書き込む"] --> name
    name["name = &quot;File uploads&quot;<br/>本文は名前を持ち、パスは持たない"]
    name -.-> tracking
    tracking["追跡マップ<br/>{ name: &quot;File uploads&quot;,<br/>paths: [&quot;src/routes/upload.ts&quot;] }<br/>パスはここにしか存在しないため、名前の変更で修正するのはこのエントリだけ"]
```

**図 5** 同一性を運ぶコンベヤー。1 つの検出事項名がすべての成果物を通って流れる一方、そのパスは追跡マップにだけ存在するため、名前の変更は 1 か所で修正されます。

通常のフローでは 2 つの操作がマップを維持し、3 つ目の操作はメンテナンスとして別に位置づけられます。**Track** は追加のみの登録です。フェーズが自分の書いた検出事項を報告すると、エンジンは新しいものを記録し、それ以外については名前の変わったパスを追跡して、それぞれを新規、移動、変更なしに分類します。フェーズが報告しなかったものを削除することは決してありません。**Untrack** は、verify が解消を確認した検出事項をクローズします。1 回の決定論的な処理の中で、各検出事項を履歴のエントリへと要約し、その節全体を成果物から削除し、最後の検出事項がなくなった成果物を削除し、追跡のエントリを取り除きます。そのため、エージェントがこれらを手作業で行うことはありません。クローズされた名前がまだ別の検出事項の本文で引用されているなど、決定論的な処理では安全に進められない箇所については、編集を推測するのではなく、その箇所をエージェントに指摘します。この 2 つが、フェーズが実行中に呼び出す操作です。**Repair** はメンテナンスのための操作です。フェーズは自身の照合で追跡の不整合（記録されたパスがもう存在しない）を見つけると、自動的に Repair に処理を委ね、それ以外の場合は必要に応じて実行されます。Repair はすべての成果物と現在のコードを読み取り、各項目のパスを修正してマップ全体を一度に整え直し、自分だけでは判断できないもの、つまり孤立項目（どの成果物にももう名前が出てこない追跡項目）やリネーム候補（パスが、報告された別の名前と一致する項目）を提示します。

Repair はメンテナンスであり、6 番目のフェーズではありません。ユーザーのコードにも文章の成果物にも触れず、追跡情報だけを扱います。ユーザーのソースを読むのは、名前の変わったファイルの新しいパスを知るためだけであり、セキュリティの内容を書くことは決してありません。エンジンが推測を拒む唯一の判断、つまり消えた項目が解決されたのか、単に名前が変わっただけなのかについては、人間が最終的な判断者です。推測するより、尋ねることを優先します。誤って削除された項目はチェーンを壊すからです。

方法論は、自らの防御の規律を自分自身にも適用します。決定論的なエンジンはコマンドラインプログラムとして呼び出され、各入力は個別のプロセス引数として渡されます。これにより入力は単なる値として扱われ、引用符やバッククォートを含む値がコマンドに注入されることは決してありません。未知のチェックは答えを返すのではなく失敗するため、スペルを間違えたチェックが問題なしの結果と読み取られることはありません。SDH は、自らの内部の仕組みもデフォルトで安全という原則の例外にはしません。

---

## XII. 基盤：移植性を証明するエージェント非依存のアーキテクチャ

SDH がほかの人々に採用される規約となるには、特定のエージェントや技術スタックに縛られてはなりません。そのため、SDH の基盤は 3 つの関心事を分離しています（図 6）。Lagune は、これが実現可能であることを証明しています。

**セキュリティ上の価値**は一度だけ書かれ、どのエージェントがそれを実行するかについては何も知りません。フェーズの指示とそれが埋めるテンプレート、知識カタログ、決定論的なエンジンがこれにあたります。**配布**は薄い層です。その唯一の役割は、その価値を各エージェントが期待する形と場所で届けることであり、独自のセキュリティロジックは一切持ちません。**プロジェクトの状態**はプロジェクトのものです。セキュリティ原則、フェーズの成果物、追跡マップ、選んだカテゴリ、独自の専門知識がこれにあたり、コードのほかの部分と同様にコミットされ、レビューできます。

```mermaid
flowchart TB
    value["一度だけ書かれるセキュリティ上の価値<br/>フェーズの指示 · テンプレート · 知識カタログ · 決定論的なエンジン<br/>どのエージェントが実行するかを知らない"]
    delivery["配布<br/>その価値を各エージェントが期待する形で届ける<br/>セキュリティロジックを持たない"]
    agent["エージェント<br/>フェーズを実行する"]
    project["プロジェクトの状態<br/>コードとともにコミットされる<br/>セキュリティ原則 · フェーズの成果物 · 追跡 · カテゴリ · 独自の専門知識"]
    value --> delivery --> agent
    agent -->|"読み取りと書き込み"| project
```

**図 6** エージェント非依存の基盤。セキュリティ上の価値は一度だけ書かれ、薄い配布層がそれを各エージェントに届け、状態はプロジェクトのものであり続けます。

配布はセキュリティロジックを持たないため、それがどう作られていても SDH には何の変化もありません。基盤は配布を自前で構築することも、リファレンス実装のように、エージェントのスキルをすでに配布しているエコシステムに任せることもでき、どちらの場合もフェーズ、その成果物、その保証は変わりません。また、これらはいずれも特定の言語やランタイムに固有のものではありません。リファレンス実装はたまたま 1 つの技術スタックで書かれていますが、方法論とはこれらの関心事のあいだの境界であって、それらを構築するツールチェーンではありません。同じ設計をまったく別の言語で再実装しても、SDH の本質は変わりません。

---

## XIII. 実例：SDH を最初から最後まで

> **実例**
>
> **アップロード機能と管理画面の攻撃対象領域に対する防御的な堅牢化**
> **コンテキスト**：ユーザーがアップロードしたファイルを受け付け、管理ページに一覧表示する小さなアプリ。
> **パターン**：charter → detect（コンテキストによって有効化されるオンデマンドの知識を含む）→ plan → harden → verify の流れと、1 回のクローズ、1 回の本物の失敗。
> **結果**（能力）：解消が検証され、チェーン全体からクローズされた 1 つのリスクと、解消*されていない*と検証され、harden へ差し戻された 1 つの対策。判定は記録ではなくコードを反映します。

_これは方法論の仕組みを説明するための例であり、実地で測定した研究ではなく、有効性の指標も報告しません_。

1 つの連続したウォークスルーで、方法論の部品だけでなく、方法論が動いている様子を示します。`§IV` のファイルアップロードの例を拡張し、オンデマンドの知識の有効化とクローズを加え、さらに 1 つの本物の失敗を含めます。

1. **charter** が "すべての入力は検証されるまで信頼できない" という原則を提案し、そのリスクを平易な言葉で添えます：チェックされていない入力は、システムが破られる最もよくある経路です。
2. **detect** は、アップロードのルートと、アップロードされたファイルを一覧表示する小さな管理ページをスキャンします。アップロードに関する検出事項（ハンドラーがクライアントの MIME タイプを信頼している）を見つけます。管理ページはブラウザで動作し、これはオンデマンドプロンプト（`§VII`）が認識するコンテキストなので、detect はそのコンテキスト向けの専門知識を読み込み、2 つ目の検出事項を提示します。ファイル名がテキストではなくマークアップとしてページに書き込まれている箇所があり、細工された名前が訪問者のブラウザでスクリプトとして実行されうるというものです。この範囲にコンテキストが存在しない専門知識は読み込まれず、各スキップは、コードから読み取った不在の根拠とともに記録されます。
3. **plan** はアップロードの修正の優先度を緊急とし、原則と結び付けます：ファイルの実際の種類とサイズを確認し、保存時に名前を変更し、コードが実行されない場所に保存します。2 つ目の修正の優先度は重要とします：ファイル名をマークアップではなくテキストとして描画します。
4. **harden** は、まずアップロードの修正を適用して（優先度が最も高いため）Applied と記録し、次に 2 つ目の修正を適用して、これも Applied と記録します。
5. **verify** は各箇所を読み取り、コードと記録を突き合わせます。アップロードの対策は有効です。ハンドラーは内容から実際の種類を判別し、サイズ制限を適用し、それ以外を拒否しています。判定は Risk closed です。verify はアップロードの検出事項をチェーン全体からクローズし、その要約が履歴に記録されます。

続いて本物の失敗です。harden の 2 つ目の修正が、テキストを安全に描画するヘルパーを追加したものの、マークアップを書き込む古い呼び出しが別のコード経路でまだ到達可能なまま残っていたとします。verify はページを読み取り、安全なヘルパーを確認すると同時に、安全でない経路がまだ生きていることも確認します。対策は存在しますが、リスクは解消されていません。verify は記録に合わせて判定を甘くすることを拒みます。"Risk not closed" を返し、不足点を記録し、harden へ差し戻します。リスクに完全には対処していない対策は、合格ではありません。

この 1 つの例に、方法論の特徴が表れています。コンテキストを認識した検出、原則と結び付いた優先順位付きの修正、慎重な適用、そして記録にかかわらずコードの実際の状態を報告する検証です。

---

## XIV. SDH を使うべきとき、そしてその限界

SDH は状態非依存でクローズ可能なので、重いプロセスにありがちな過剰さに陥ることはめったにありません。単一のファイルや単一の懸念にまで規模を縮められ、負担を残し続けるのではなく静止状態に達します。SDH の境界はプロジェクトの規模ではなく、**保証の深さ**にあります。

```mermaid
flowchart TB
    q1{"コードはセキュリティに関わることを何かしているか？<br/>（入力、認証、データ、シークレット、外部呼び出し）"}
    q1 -->|いいえ| little["ここでは SDH の効果は小さい。"]
    q1 -->|はい| q2{"SDH を実行する。コンプライアンス上の基準、<br/>または専任のセキュリティ部門はあるか？"}
    q2 -->|いいえ| baseline["SDH が根拠のあるベースラインになる。"]
    q2 -->|はい| carrier["SDH は構造化された基盤：<br/>専門家によるレビューと監査を支えるが、<br/>それらに取って代わるものではない。"]
```

**図 7** SDH を使うべきとき。分岐の基準はまずセキュリティとの関連性、次に保証の深さであり、プロジェクトの規模ではありません。

SDH が境界に達するのは、次のような場合です。システムの実行時にしか現れない振る舞い（verify はコードを読むのであって、システムを実行するわけではありません）、エージェントが読み取れない設定や環境に依存するリスク、そして何があっても専門家のレビューが必要な、重大な影響をともなう状況です。いずれの場合も、SDH は構造化された最初のチェックとして価値を加えますが、それは下限であって、上限ではありません。

> **要点**
>
> **境界**：SDH の限界は保証の深さであり、プロジェクトの規模ではありません。ほぼどこでも根拠のあるベースラインとして機能し、重大な影響がかかる場面では専門家のレビューを支えますが、稼働中のシステムに対するテストや、セキュリティの専門家の判断に取って代わるものではありません。

---

## XV. 考察：位置づけ、限界、そして SDH が主張しないこと

SDH は、自らの境界を厳密に定めています。

### 拡張するのであって、置き換えるのではない

SDH は、セキュリティの専門家や専門的な Blue Team ツールに取って代わるものではありません。開発者の知識を拡張するものです（`§VI`）。控えめな主張こそが妥当です。うまく適用すれば、SDH は実在するリスクを効果的に解消**できます**。特に、そうでなければセキュリティチェックをまったく受けないプロジェクトにとってはそうです。とはいえ保証ではなく、重大な影響がかかる場面で専門家のレビューの代わりになるものでもありません。

### 設計段階から防御専用

SDH は監査し、堅牢化し、検証します。攻撃用ツール、エクスプロイト、危害を目的とした検知回避は決して生み出しません。デュアルユースのセキュリティ情報は、明確に防御的で、許可を得た文脈でのみ許容されます。これは好みではなく、越えられない境界です。

### 検証は見せかけではなく実質的

verify は、システムを動かすのではなく、コードを読み取って記録と突き合わせることで検証します。これは静的な検証です。対策がコードの中に存在し正しいことは確認しますが、実行時に攻撃を受けても対策が有効であることは証明しません。したがって "Cannot tell from the code" は正当な判定であり、合格の結果の陰に隠された失敗ではありません。証拠がコードの中にない場合（設定や、エージェントが読み取れないパスに依存している場合）、SDH は推測せずにそう伝えます。

### 決定性は範囲を限定し、明示する

SDH の大部分はエージェントの推論に基づいており、それがコンテキスト認識を可能にしています。決定性は決定論的なエンジン、つまり専門知識が持ちうるチェッカー（`§VII`）と追跡エンジン（`§XI`）に限定されています。本稿はこの線引きをあいまいにしません。結果が決定論的であれば、それはプログラムの結果です。推論によるものであれば、それはエージェントによるコードの読み取りであり、最終的な判断者はユーザーです。

### コストと規模

全体のスキャンは多くのトークンを消費します。手動モード（`§VI`、`§VIII`）が存在する理由の 1 つは、コストを懸念の大きさに見合ったものに保つことです。

### 最終的な判断者はユーザー

SDH は、名前が変わっただけか解決されたのかの判断を人間に委ねます。また、コード編集の承認は、ユーザーがすでにエージェントを管理している場所、つまりエージェントを動かしている権限モードに残ります。方法論は提案し、検証します。人の判断を覆すことはしません。

### 反論と応答

公平な懐疑論者なら、いくつかの反論を挙げるでしょう。そのうち実質的なものは、反論者自身の言葉で提示する価値があります。

"**これは、静的解析ツールに LLM を後付けしただけではないのですか**？" 違います。静的解析ツールは、持っているすべてのルールをデフォルトで実行します。SDH はまずシステムが何であるかを検出し、それから関連する知識を手に取ります（`§II`、`§VII`）。そして、決定論的なチェッカーを*組み込む*のは、リスクの種類に明確な判定手順がある場合だけです。推論はコンテキストを優先し、決定性は的を絞って使われます。

"**これは、単なるセキュリティのチェックリストではないのですか**？" 違います。SDH はチェックリストを逆転させます。検出が先にあり、知識はプロジェクトが実際に行っていることに合わせて取り込まれます（`§II`、`§VII`）。

"**これは、SDD をセキュリティ向けに名前を変えただけではないのですか**？" 違います。SDH は SDD の構造を借りながら、その契約を反転させています。強制力、状態の前提、終了条件、誰に応えるかがすべて異なります（`§X`）。仕組みは同じでも、方向は正反対です。

"**AI の推論に頼る方法では、ハルシネーションで存在しない検出事項を作り出すだけではないのですか**？" この設計は、モデルが行儀よく振る舞うと信頼するのではなく、創作そのものを制約しています。detect はコードが裏付けることだけを記録し（"創作ではなく検出"、`§IV`）、verify はコードと記録を突き合わせて "Cannot tell from the code" と答えることができ（`§XV`）、決定論的なチェッカーが判定可能なケースの根拠となり（`§VII`）、最終的な判断者はユーザーです。これでエージェントが誤りを犯さなくなるわけではありませんが、その主張を検証可能なものにします。

位置づけについて補足します。本稿では、SDH をそのリファレンス実装から独立して定義しています。5 つのフェーズ、リスクを軸にしたセキュリティ原則、追記せず照合する規律とそのクローズ可能性、オンデマンドプロンプトの知識、予防モード、名前による識別の追跡、そして防御専用という境界こそが方法論です。ほかのチームが別の技術スタックや別のエージェントのエコシステムでこれらを実装しても、その結果はやはり SDH です。Lagune は SDH の証明であって、定義ではありません。

---

## XVI. 落とし穴と、SDH がそれを構造的に避ける方法

この系統の方法論には、共通して知られている一連の失敗モードがあります。SDH はその大半に構造で応えます。規律に任せるのではなく、フローそのものに組み込んでいるのです。

| 落とし穴                         | 失敗                                                    | SDH の構造的な答え                                                                                                               |
| -------------------------------- | ------------------------------------------------------- | -------------------------------------------------------------------------------------------------------------------------------- |
| 仕様の腐敗、古くなったバックログ | 成果物に、誰も信頼しない死んだエントリが溜まっていく    | 追記せず照合する（`§V`）：実行のたびにすべてのエントリを再確認し、解決したものを削除する                                         |
| 誤った安心感、見かけ上の合格     | 対策が存在すればリスクは解消されたと見なされる          | verify がコードと記録を突き合わせるため、"Risk not closed" と "Cannot tell" も正式な判定になる（`§IV`、`§XV`）                   |
| チェックリストの氾濫             | 汎用的な項目が、本当に重要な 1 つのリスクを埋もれさせる | 汎用性よりコンテキスト認識を優先し、オンデマンドプロンプトで範囲が必要とするものだけを読み込む（`§VII`）                         |
| ツールへのロックイン             | 方法が 1 つのベンダーやエージェントに固く結び付けられる | エージェント非依存の基盤：セキュリティ上の価値は一度だけ書かれ、各エージェントへの配布はセキュリティロジックを持たない（`§XII`） |
| 終わりのないループ               | バックログが決して閉じず、作業が休まらない              | クローズ可能性と静止状態（`§V`）                                                                                                 |

**表 4** この系統の方法論で知られている落とし穴と、それぞれに対する SDH の構造的な答え。

要点は、落とし穴に名前を付け、仕組みを指し示すことにあります。これらは注意を促す警告ではなく、フローそのものが持つ性質です。

---

## XVII. 今後の課題

方法論とそのリファレンス実装には、明確な次のステップがあります。

- **知識カタログの拡充**：
  追加はどれも `§VII` の形を保ちます。知識ファイル 1 つとカタログの 1 行で、新しいコマンドは不要です。ユーザー側の手段は、そこにすでに用意されています。ユーザーは自分の専門知識を必要に応じて抽出できます。メンテナー側の方向性は、組み込みの言語、ランタイム、リスクの種類を増やし、それぞれをいずれかのカテゴリに加えていくことです。専門知識は進化していくことが想定されています。
- **決定論的なチェッカーの追加**：
  あるリスクの種類に明確な判定手順がある場合、専門知識は決定論的なチェッカーを持つことができ、エージェントの推論を再現可能な判定に根ざさせます。これをより多くのリスクの種類に広げることは、自然な方向性です。
- **実証的な評価**：
  最も大きな未解決の問いは、測定された有効性、つまり実際のコードベースにおけるクローズの質と誤判定の割合です。SDH のセキュリティ上の成果に関する研究は今後の課題であり、本稿の主張もそれに応じて範囲を限定しています。

---

## XVIII. 結論

AI 支援開発は、汎用的なチェックリストでは埋められないセキュリティのギャップを生みました。重要なリスクはシステムが実際に何をしているかに固有であり、それをリリースする人は何を尋ねればよいかを知らないかもしれないからです。SDH はこのギャップを、コンテキストを認識し、防御専用で、クローズ可能なフローによって埋めます。このフローでは、セキュリティの知識は方法論とオンデマンドの専門知識に宿り、すべてのユーザーが積み上げていけるベースラインとなります。SDH はシステムの実際のコンテキストを検出し、そのコンテキストが抱えるリスクをトリアージし、修正を慎重に適用し、一つひとつを検証したうえで、解消したものをクローズし、各検出事項が最終状態に達するようにします。同じ防御は新しい作業の構築中にも予防的に働くため、フローで解消したものは解消されたまま保たれます。SDH はどの技術スタックのどの開発状態にも適応し、すでにその役割を担っている人やツールに取って代わるのではなく、開発者の知識を拡張します。

Lagune は証明ですが、貢献はこの規約にあります。SDH を、ほかの人々が採用し、改良し、それぞれの技術スタックで実装できる、AI とともに開発する時代に欠かせないセキュリティのフローとして提案します。

---

## 参考文献

**[1]** D. B. Piskala, "Spec-Driven Development: From Code to Contract in the Age of AI Coding Assistants," arXiv preprint arXiv:2602.00180v1 [cs.SE], Jan. 2026. (Submitted to AIWare 2026.) [Online]. Available: https://arxiv.org/abs/2602.00180

**[2]** GitHub, "Spec Kit: Toolkit for Spec-Driven Development." [Online]. Available: https://github.com/github/spec-kit. Accessed: 2026.

**[3]** Fission AI, "OpenSpec: Spec-Driven Development for AI Coding Assistants." [Online]. Available: https://github.com/Fission-AI/OpenSpec. Accessed: 2026.

**[4]** B. Chess and G. McGraw, "Static Analysis for Security," IEEE Security & Privacy, vol. 2, no. 6, pp. 76-79, 2004, doi: 10.1109/MSP.2004.111.

**[5]** OWASP Foundation, "Source Code Analysis Tools." [Online]. Available: https://owasp.org/www-community/Source_Code_Analysis_Tools. Accessed: 2026.

**[6]** OWASP Foundation, "OWASP Top 10:2021." [Online]. Available: https://owasp.org/Top10/. Accessed: 2026.

**[7]** MITRE, "Common Weakness Enumeration (CWE)." [Online]. Available: https://cwe.mitre.org/. Accessed: 2026.

**[8]** N. Perry, M. Srivastava, D. Kumar, and D. Boneh, "Do Users Write More Insecure Code with AI Assistants?," in Proc. ACM SIGSAC Conf. on Computer and Communications Security (CCS '23), 2023, pp. 2785-2799, doi: 10.1145/3576915.3623157. [Online]. Available: https://arxiv.org/abs/2211.03622

**[9]** J. Davis and contributors, "safe-regex: Detect Possibly Catastrophic, Exponential-Time Regular Expressions." [Online]. Available: https://github.com/davisjam/safe-regex. Accessed: 2026.

**[10]** D. Soshnikov, "regexp-tree: Regular Expressions Processor in JavaScript." [Online]. Available: https://github.com/DmitrySoshnikov/regexp-tree. Accessed: 2026.

**[11]** T. Jenkinson, "redos-detector: A CLI and Library to Score How Vulnerable a Regex Pattern Is to ReDoS Attacks." [Online]. Available: https://github.com/tjenkinson/redos-detector. Accessed: 2026.

---

## 付録 A：原則の全文

1. **デフォルトで安全、平易な言葉で、すべての人に平等に**：
   すべてのデフォルト、メッセージ、修正は、最初から安全で、開発者かどうかを問わずどのユーザーにも理解できるものでなければなりません。特定のユーザー層がほかより優遇されることはありません。
2. **汎用性よりコンテキスト認識**：
   すべてのフェーズは、detect で検出したコンテキストから出発し、システムが実際に行っていることに基づいて動かなければなりません。汎用的なチェックリストより、そのコンテキストに固有の推奨事項を優先します。セキュリティの知識は仕様とオンデマンドの専門知識に宿り、ユーザーが持ち込む知識を何であれ拡張します。
3. **硬直性より柔軟性**：
   SDH はプロジェクトとユーザーに合わせて柔軟に形を変えます。原則、要件、推奨事項は出発点であり、固定の契約ではありません。ユーザーがどれでも言い換え、削除、追加、範囲の縮小をできるようにします。柔軟性がデフォルトで安全なベースラインを弱めることは決してなく、ベースラインの適用の仕方をユーザーが形づくれるようにするだけです。
4. **追記のみにせず、照合する**：
   成果物はログではなく、生きたドキュメントです。フェーズを再実行するときは、既存の各エントリを現在の実態と照合し、今も有効なものは残し、変わったものは書き直し、もう当てはまらないものは削除します。クローズとは、この同じ照合が結論に達したものです。
5. **防御専用**：
   SDH は監査し、堅牢化し、検証します。攻撃用ツール、悪用目的のエクスプロイト、危害を目的とした検知回避は決して生み出しません。デュアルユースのセキュリティ情報は、明確に防御的で、許可を得た文脈でのみ許容されます。
6. **仕様ファースト、エージェント駆動、セキュリティ志向**：
   実績のある構造、つまりテンプレート、コマンド、規範となるセキュリティ原則、各フェーズを実行するエージェントからワークフローを組み立てます。その構造を、防御を目的として再実装します。

---

# Lagune 用語集：SDH、charter、検出事項、対策

> Lagune と Security-Driven Hardening のすべての用語を、わかりやすい言葉で定義します。SDH、charter、detect、検出事項、対策、harden、verify、クローズ、クローズ可能性、専門知識、カテゴリ、カタログを収録しています。

正規 URL: https://lagune.ai/ja-JP/docs/references/glossary
言語: ja-JP
原文: https://lagune.ai/docs/references/glossary
最終更新日: 2026-11-03

Lagune と Security-Driven Hardening の方法論で要となる用語をすべて、わかりやすい言葉で一度ずつ定義します。

### Security-Driven Hardening (SDH)

Lagune が実装する方法論で、コンテキストを踏まえた Blue Team の規約です。システムのコンテキストを検出し、そのコンテキストに伴うリスクをトリアージして、修正へと導きます。セキュリティの知識は仕様と、必要なときだけ読み込む専門知識に収められているので、開発者でもそうでなくても、同じフローで支援を受けられます。

### Lagune

SDH のリファレンス実装です。9 つのエージェント向けコマンドと、各コマンドが埋めるテンプレートからなり、AI エージェントがこれを実行してコードベースを堅牢化します。各エージェントは、独自のプラグインインストーラーか [**skills.sh**](https://www.skills.sh/wellwelwel/lagune) からコマンドをインストールします（[インストールページ](https://lagune.ai/ja-JP/docs) を参照）。決定論的なステップは、どれもコマンドが Lagune のエンジンで実行します。

### Charter（セキュリティ原則）

Lagune 全体を統括するレイヤーで、後続のすべてのフェーズが守るべき、セキュリティを最優先にした原則の集まりです。プロジェクトのセキュリティ態勢に対する、コンパイル時のチェックだと考えてください。保存先は `.lagune/memory/charter.md` です。

### 開発フロー

書いているその場で作業を堅牢化する汎用コマンド `/lagune` です。どの段階のどんなプロンプトでも受け付け、依頼された内容を作り、安全なデフォルト設定で堅牢化してから返します。セキュリティ原則があれば、それを指針にします。Lagune の追跡情報には何も書き込まないため、生み出すのは堅牢化されたコードだけです。事前に定めるセキュリティ原則、事後の Blue Team フローとあわせて、開発中に Lagune がプロジェクトを守る手段です。

### Blue Team フロー

Lagune の中核をなす、charter、detect、plan、harden、verify の 5 フェーズからなる監査です。各フェーズは前のフェーズを土台にします。"Blue Team" はセキュリティにおける防御側の伝統を指し、攻撃側の Red Team と対をなします。

### 検出事項（Finding）

検出されたひとつのリスクです。各検出事項には、それが何か、なぜ重要か、コード上の根拠が記されます。検出事項は plan、harden、verify が引き継いでいく単一の追跡単位で、どの成果物でも名前で識別されます。

### 対策（Control）

リスクを解消するために適用するセキュリティ上の措置です。harden が対策を適用し、verify がその有効性を証明します。Lagune がプロンプトに合わせて対策を弱めることは決してありません。

### Detect

コードを読み、システムが何をしているか、どこにリスクがあるかを洗い出すフェーズです。根本のルールは、作り出すのではなく検出することです。コードで裏付けられることだけを記録します。

### Harden

コードに手を加える唯一のフェーズです。plan の修正をひとつずつ適用し、それぞれを Applied、Partial、Blocked のいずれかとして記録します。Applied の時点では、まだ証明はされていません。

### Verify

コードを読んで harden の記録と突き合わせ、適用した各修正が有効であることを証明するフェーズです。判定は Risk closed、Risk not closed、Cannot tell from the code の 3 つのいずれかです。

### クローズ（Stand down）

verify がリスクの解消を証明すると、その検出事項をクローズします。確認を得たうえでチェーン全体から取り除き、以後は再処理しません。

### クローズ可能性（Closability）

セキュリティ作業には終わりがある、という性質です。解消が証明された検出事項をクローズするので、フローを静止状態にでき、再開するのはコードが変わったときだけです。SDH は終わりのないループではなく、クローズできる仕組みです。

### エンジン（Engine）

**npm** 上の `lagune` パッケージです。決定論的なステップ（フック、カタログ、カテゴリ）はすべて、コマンドが `npx` を通じてこのパッケージで実行します。

### 専門知識（Specialization）

特定のテーマに絞った、プログラミング言語に依存しないセキュリティ知識のモジュールです。デフォルトでは読み込まれず、必要なときだけ読み込まれます。専門知識はコマンドではありません。エンジンの `read catalog <name>` を使えば、どのプロンプトにも読み込めます（例：`npx lagune read catalog regex`）。

### カテゴリ（Category）

組み込みの専門知識を名前付きでまとめたグループで、`owasp` から、`javascript`、`python`、`go`、`rust` のような言語別のものまであります。プロジェクトが使うカテゴリは `.lagune/configs.json` に記録され、どの組み込み専門知識がそのカタログに加わるかを決めます。何も記録されていない間、プロジェクトは `owasp` だけを使います。

### カタログ（Catalog）

プロジェクトが使う専門知識の集まりです。そのカテゴリに属する組み込みの専門知識と、`/lagune-specialize` で書いた独自の専門知識からなります。エンジンの `read catalog` で一覧を表示でき、各フェーズはこれをコードと照らし合わせます。

### オンデマンドプロンプト（Prompt-on-demand）

すべてのチェックをデフォルトで実行するのではなく、プロジェクトの実態に合ったセキュリティ知識を必要に応じて取り込む、という原則です。

### 名前による識別（Identity-by-name）

Lagune の追跡モデルです。各検出事項の名前は、すべての成果物でまったく同じ表記のセクション見出しとして書かれ、チェーン全体を通じてその検出事項の識別子になります。追跡マップ（`.lagune/tracking.json`）が保持するのは追跡情報だけで、説明文は一切持ちません。

## よくある質問

### Security-Driven Hardening（SDH）とは何ですか？

SDH は、コンテキストを踏まえた Blue Team のセキュリティ方法論です。システムのコンテキストを検出し、そのコンテキストに伴うリスクをトリアージして修正へと導き、検出事項はすべてわかりやすい言葉で示します。Lagune はそのリファレンス実装です。

### Lagune の charter とは何ですか？

charter は Lagune 全体を統括するレイヤーで、後続のすべてのフェーズが守るべき、セキュリティを最優先にした原則の集まりです。保存先は .lagune/memory/charter.md です。

### 検出事項をクローズするとはどういう意味ですか？

verify がリスクの解消を証明すると、その検出事項をクローズします。確認を得たうえでチェーン全体から取り除き、以後は再処理しません。

---

# 設定スキーマ

> Lagune プロジェクトの設定ファイルに使う JSON Schema です。エディターでの自動補完と検証に使え、最新の Lagune に追従させることも、特定のバージョンに固定することもできます。

正規 URL: https://lagune.ai/ja-JP/docs/references/configs-schema
言語: ja-JP
原文: https://lagune.ai/docs/references/configs-schema
最終更新日: 2026-11-03

`.lagune/configs.json` は、プロジェクトが使う [**カテゴリ**](https://lagune.ai/ja-JP/docs/categories) を記録し、プロジェクト独自の [**専門知識**](https://lagune.ai/ja-JP/docs/catalog) の索引を持つファイルです。この JSON Schema を使うと、ファイルを編集している間、エディターが各フィールドを自動補完し、タイプミスや存在しないカテゴリを指摘してくれます。

## 最新のスキーマ

**Lagune** はこのファイルを書き込むとき、`$schema` が見つからなければ、ファイルが最新のスキーマを指すように設定します：

```json
{
  "$schema": "https://lagune.ai/schemas/configs.json",
  "categories": ["owasp", "javascript"]
}
```

このアドレスは常に最新の **Lagune** に追従します。**Lagune** 0.16.0 より前に書かれたファイルには次に変更されるときに追加され、それまではどのフェーズもそのことを知らせます。

## バージョンを固定する

0.16.0 以降の **Lagune** の各リリースには、そのバージョン時点のスキーマが含まれており、**npm** で公開され、**jsDelivr** から配信されます。バージョンを固定するには、`lagune@` の後ろにバージョンを書いたアドレスを `$schema` に指定します：

```json
{
  "$schema": "https://cdn.jsdelivr.net/npm/lagune@0.16.0/schemas/configs.json"
}
```

バージョンには任意の semver 範囲を指定できます：

| バージョン             | スキーマ                        |
| ---------------------- | ------------------------------- |
| `0.16.0`               | 0.16.0 のスキーマ               |
| `0.16.x` または `0.16` | 0.16 系の最新リリースのスキーマ |
| `0.x` または `0`       | 0.x 系の最新リリースのスキーマ  |
| `latest`               | 最新リリースのスキーマ          |

## よくある質問

### Lagune の動作にスキーマは必要ですか？

いいえ。スキーマはエディターを補助するだけで、$schema があってもなくても、Lagune はファイルを同じように読み込みます。

### Lagune は固定したスキーマを上書きしますか？

いいえ。Lagune が $schema を書き込むのはファイルにまだない場合だけで、設定済みのアドレスはそのまま残します。

### どんなときにバージョンを固定すべきですか？

プロジェクトで特定のバージョンの Lagune を使っているときです。そうすれば、エディターはそのバージョンが受け付ける内容に照らしてファイルを検証します。

---

# Lagune vs. Deepsec：AI 駆動の 2 つのセキュリティアプローチを比較

> Lagune と Vercel の Deepsec を、仕組み、ライフサイクル、検出、コスト、検出事項、クローズの観点から比較したリファレンスです。

正規 URL: https://lagune.ai/ja-JP/docs/references/deepsec
言語: ja-JP
原文: https://lagune.ai/docs/references/deepsec
最終更新日: 2026-11-03

[Lagune](https://github.com/wellwelwel/lagune) と [Deepsec](https://github.com/vercel-labs/deepsec)（`v2.2.1`）は、AI 支援開発の時代のセキュリティという同じ課題に対する、2 つの防御的な答えです。仕組みが重なる部分はあっても、前提も、始まりから終わりまでの流れも、ユーザーへの見せ方も、意図して異なるように作られています。

**ヒント**

Lagune は Deepsec の影響を受けているのでしょうか？いいえ。Lagune はゼロから書かれたもので、Spec-Driven Development と Security Hardening から着想を得ています。2 つのプロジェクトはそれぞれ独立して開発されたもので、ここでの比較は、ユーザーが両者の違いを理解するためのものです。

## 概要

| 観点                 | Lagune                                                                                                                              | Deepsec                                                                                |
| -------------------- | ----------------------------------------------------------------------------------------------------------------------------------- | -------------------------------------------------------------------------------------- |
| 種類                 | リファレンス実装を備えた方法論（SDH）                                                                                               | 製品：エージェントで動く脆弱性スキャナー                                               |
| 軸                   | セキュリティ原則とオンデマンドの知識がエージェントを動かし、決定論的なフックが土台を支える                                          | 広く張った正規表現の網が、必須の AI 調査に候補を送り込む                               |
| 生み出すもの         | 堅牢化されたコード、証明、追跡される検出事項のチェーン                                                                              | 深刻度順に並べ、トリアージした検出事項のレポート                                       |
| コードに手を加えるか | はい：`harden` がコードを編集する                                                                                                   | いいえ：静的解析のみで、検出事項と推奨事項のテキストを出力する                         |
| 実行環境             | すでに使っているエージェントとモデルで動き、モデルのクラスは問わない                                                                | 独自のモデルパイプラインで動き、デフォルトはフロンティアクラスのモデル                 |
| 導入                 | プラグインを 1 つインストールするか `npx skills add` を実行したら、あとはふだんの言葉で操作するだけで、新たに立ち上げるツールは不要 | `.deepsec/` ワークスペースを用意し、依存関係をインストールして、モデルのキーを追加する |

## 仕組み

Lagune はエージェントが起点です。エージェントが作業を進め、コードの実態に合わせて必要な知識をオンデマンドで取り込み、機械的に判定できる部分は決定論的なフックに任せます。

Deepsec は決定論的な処理が起点です。広範なスキャンが候補を指摘し、その候補が、必須のモデルに調査と判断の対象を示します。

| 観点                 | Lagune                                                                                                             | Deepsec                                                      |
| -------------------- | ------------------------------------------------------------------------------------------------------------------ | ------------------------------------------------------------ |
| 順序                 | セキュリティ原則とコードに合致した知識がエージェントを導き、エージェントは一部をフックに任せて、残りを自ら判断する | マッチャーが候補を指摘し、モデルがそれぞれを調査して判断する |
| 決定論的な処理の役割 | 判定を返すか、エージェントの狙いを定める多言語対応のフックで、カテゴリの知識と組み合わせて使う                     | 候補を指摘し、必須のモデルの判断に回すマッチャー             |
| 開発フロー           | `/lagune` がコーディング中にその場で安全に構築する                                                                 | コードをレビューするだけで、書きはしない                     |
| 監査フロー           | `charter` → `detect` → `plan` → `harden` → `verify`                                                                | `scan` → `process` → `triage` → `revalidate` → `report`      |
| AI の役割            | 知識をもとに推論し、修正を適用して、それが有効であることを証明する                                                 | すべての候補を調査し、検出事項を報告する                     |

## ライフサイクル

Lagune は、コードを書く前、書いている最中、書いた後のいずれでも機能します。Deepsec は、コードができてからリポジトリをレビューします。

| タイミング       | Lagune                                                                 | Deepsec                                                                |
| ---------------- | ---------------------------------------------------------------------- | ---------------------------------------------------------------------- |
| コードを書く前   | `charter` が、示された意図からセキュリティポリシーを作り出す           | 既存のコードから始める：`init` にはディレクトリが必要                  |
| 開発中           | `/lagune` がその場で、デフォルトで安全な形に作り上げ、成果物は残さない | 開発中ではなく、開発後にレビューする                                   |
| 既存のコード     | `detect` → `plan` → `harden` → `verify`                                | `scan` → `process`（中核のフロー）                                     |
| 継続的なレビュー | 範囲ごとにフェーズを再実行する。既製の CI ゲートはない                 | インクリメンタルな再スキャンと、CI の終了ゲートになる `process --diff` |

## 検出レイヤー

両者の決定論的なレイヤーは、性質が正反対です。一方は判定し、もう一方は指摘します。

| 観点         | Lagune                                                                     | Deepsec                                                          |
| ------------ | -------------------------------------------------------------------------- | ---------------------------------------------------------------- |
| グループ分け | カテゴリごとにまとめたフックと専門知識                                     | パターンやフレームワークごとのマッチャー                         |
| 出力         | 明示的な判定（finding / review / advisory）と分類ラベル                    | 判定のない候補（slug、行、コードスニペット、マッチしたパターン） |
| チューニング | 適合率重視：コメントを認識し、プレースホルダーとウィンドウのガードを備える | 再現率重視：網を広く張り、誤検知は後から AI が取り除く           |
| 深さ         | 両者が共通して扱う種類では、より深い                                       | より広いが、両者が共通して扱う種類では浅い                       |
| 誤検知       | 発生源で低く抑え、そのうえでコンテキストに照らして判断する                 | 意図的に多めに出し、`revalidate` の工程で削る                    |

## 知識と判断

どちらも、正規表現では表せないセキュリティの知識を備えています。違いは、その知識がどこにあり、誰が形づくれるかです。

| 観点         | Lagune                                                                       | Deepsec                                                         |
| ------------ | ---------------------------------------------------------------------------- | --------------------------------------------------------------- |
| 形式         | 編集できる Markdown のモジュールで、一部は決定論的なフックに裏付けられている | 短いプロンプトと技術ごとの要点で、モデル自身の知識に頼る        |
| 選び方       | コードと照合し、該当するコンテキストがあるときだけ読み込む                   | すべての AI バッチに注入し、検出した技術の要点も加える          |
| 誰が書くか   | ユーザーがモジュールを編集し、`specialize` で新しいモジュールを追加する      | プロンプトはメンテナーが管理し、ユーザーは `INFO.md` を記入する |
| 判断の担い手 | フックが土台となる部分を判定し、残りはエージェントが知識をもとに判断する     | 集中型：1 つの AI プロセッサーがすべての候補を判断する          |
| 再利用       | 1 つのモジュールが `detect` と `verify` の両方を導く                         | 1 つのプロンプトが、唯一の `process` ステージを動かす           |

## 検出事項とクローズ

両者がもっとも大きく異なるのは、解決した検出事項がその後どうなるかです。

| 観点         | Lagune                                                                       | Deepsec                                                                   |
| ------------ | ---------------------------------------------------------------------------- | ------------------------------------------------------------------------- |
| 深刻度       | 露出度と事の重大さに応じて調整した CVSS v4.0 スコア                          | AI が付ける深刻度に加え、悪用可能性と影響による P0 / P1 / P2 のトリアージ |
| 判定         | Risk closed、Risk not closed、Cannot tell from the code のいずれか           | true-positive、false-positive、fixed、uncertain、accepted-risk、duplicate |
| 保存のしかた | 作業中のチェーンは現状と照合して更新し、クローズした検出事項は履歴に要約する | ファイルごとの追記専用の記録で、何も削除しない                            |
| 最終状態     | クローズ可能：証明済みの検出事項はクローズされ、チェーンを静止状態にできる   | すべての検出事項を永久に保持し、解決後はビューから非表示にする            |
| 履歴の詳しさ | どんなリスクだったかの簡潔な要約                                             | どう修正したかを含む、判定の全経緯                                        |

## コスト

| 観点           | Lagune                                                                                                                             | Deepsec                                                                                                                                                                                                                   |
| -------------- | ---------------------------------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| 決定論的な土台 | 無料：フックは AI もキーも使わずに動き、その時点で判定を出す                                                                       | 無料：`scan` は AI なしで動くが、単体では判定を出さない                                                                                                                                                                   |
| 一般的な費用   | すでに使っているエージェントの費用に含まれ、ローカルモデルなら $0 で済み、ほかは契約中のプランの料金か、API 利用なら反復ごとの課金 | [100 から 2,000 ファイルで 1 回あたり約 $25 から $1,200、規模が大きいとさらに高額](https://github.com/vercel-labs/deepsec/blob/f75a16803ec5250938bacfe41571d929e8564f45/docs/getting-started.md#run-the-ai-investigation) |
| 最安の方法     | 無料のローカルモデルを含め、どのモデルでもサイクルを完結できる                                                                     | より安い有料クラスのモデルもあるが、検出事項を得るには有料の AI ステージが必要                                                                                                                                            |

## 拡張性とガバナンス

それぞれ、相手が閉じているレイヤーを開いています。

| 観点             | Lagune                                                         | Deepsec                                                      |
| ---------------- | -------------------------------------------------------------- | ------------------------------------------------------------ |
| 拡張できるもの   | モジュールを編集するか、`specialize` で新しく追加する          | マッチャー、エージェント、通知機能、所有者情報を追加する     |
| ポリシー層       | セキュリティ原則がすべてのフェーズを律し、バージョン管理される | 設定は運用面のもの（マッチャー、モデル、パス）               |
| 名前による上書き | 改良したモジュールが、同名の組み込みモジュールに優先する       | マッチャーの slug が衝突すると、自分のマッチャーが優先される |

## インターフェース

Deepsec は、セキュリティ組織向けのアウトプットを生成します。Lagune は、実行している本人に向けてリアルタイムのビューを表示します。

| 観点             | Lagune                                                                     | Deepsec                                                                           |
| ---------------- | -------------------------------------------------------------------------- | --------------------------------------------------------------------------------- |
| 人が見る画面     | チェーン全体をわかりやすい言葉で示す、ローカルのリアルタイムダッシュボード | レポート、エクスポート、メトリクス、PR コメントの各ファイルと、ドキュメントサイト |
| 責任の所在       | 関係するファイルと、適用された専門知識を示す                               | 担当者の候補を割り振る：オンコール担当、マネージャー、コミッター                  |
| 再現可能な証明   | `prove` が実行可能なテストと、開示用のセキュリティアドバイザリを作成する   | 設計上あくまで静的で、対象を実行することはない                                    |
| ツール自身の防御 | ダッシュボードのローカル書き込み API を堅牢化する                          | 信頼できない対象コードに備えて、自身の AI 実行を堅牢化する                        |

## 規模とデプロイ

| 観点         | Lagune                                                                                            | Deepsec                                                     |
| ------------ | ------------------------------------------------------------------------------------------------- | ----------------------------------------------------------- |
| インストール | エージェントのプラグインか skills CLI から 9 つのコマンドを導入するだけで、ひな形は何も生成しない | 独自のパッケージと依存関係を持つ `.deepsec/` ワークスペース |
| 規模の方向性 | 任意の範囲に絞り込める：1 つのコンテキスト、1 ファイルからプロジェクト全体まで                    | リポジトリ全体をスキャンし、大規模なモノレポにも対応する    |
| 分散実行     | ローカルのみで、唯一のサーバーはループバックにバインドする                                        | 必要に応じて Vercel Sandbox のワーカー VM に分散できる      |

## ユーザー体験

それぞれが実行する人をどう迎えるか、つまり初回の実行に何が必要で、操作する人がどう狙いを定めるかです。

### 使い始め

Lagune は、すでに開いているエージェントを通じて動きます。Deepsec は、まず独自のワークスペースとモデルへのアクセスを用意します。

| 観点                 | Lagune                                                                                            | Deepsec                                                                                       |
| -------------------- | ------------------------------------------------------------------------------------------------- | --------------------------------------------------------------------------------------------- |
| 最初のコマンド       | プラグインのインストールか `npx skills add wellwelwel/lagune`、そのあとエージェントで `/lagune-*` | `npx deepsec init`、続いて `cd .deepsec`、`pnpm install`、`scan`、`process`                   |
| 実行に必要な認証情報 | 別途キーは不要で、今使っているエージェントをそのまま使う                                          | モデルのキー（例：AI Gateway、有効期限 12 時間の Vercel OIDC トークン、Anthropic のトークン） |

### 操作のしかた

どちらも指示を受け付けます。Lagune は、フェーズごとに入力の形を読み取ります。Deepsec は、同じ調査を実行する対象のファイルを絞り込みます。

| 観点             | Lagune                                                                                        | Deepsec                                              |
| ---------------- | --------------------------------------------------------------------------------------------- | ---------------------------------------------------- |
| プロジェクト全体 | 入力なしでフェーズを実行すると、範囲全体をスキャンする                                        | `scan` と `process` がリポジトリ全体をスキャンする   |
| 一部分           | どのフェーズも、指定したファイルやディレクトリに範囲を絞れる                                  | `--files`、`--files-from`、`--diff` で実行範囲を絞る |
| 特定の懸念       | フェーズを、説明した懸念に絞り込める                                                          | 調査用のプロンプトは固定                             |
| 優先度の区分     | `harden` と `verify` を緊急、重要、警告、注意のいずれかに絞り込める                           | 検出事項のラベル付けは実行後                         |
| 単一の値         | フックが 1 つのコードスニペット、パターン、URL を直接スコアリングする（`--pattern`、`--url`） | 作業の単位はファイル                                 |

## よくある質問

### Lagune と Deepsec は何が違うのですか？

Lagune はエージェントが起点で、コードを書く前、書いている最中、書いた後のいずれでも機能します。コードを書く前にポリシーを定め、開発中はその場で堅牢化し、すでに書かれたコードは監査、堅牢化、検証します。Deepsec は決定論的な処理が起点です。広範な正規表現スキャンの結果を必須のフロンティアモデルによる調査に送り、その調査が既存のコードをレビューして検出事項を報告しますが、コードは変更しません。

### どちらも無料で使えますか？

Lagune はフロー全体を無料のローカルモデルで $0 で実行でき、決定論的なフックは AI をまったく使わずに判定を出します。Deepsec のスキャンは無料ですが判定を出さないため、検出事項を得るには必ず有料の AI ステージが必要です。

### コードを変更するのはどちらですか？

Lagune は変更します。harden がコードに修正を適用します。Deepsec は変更しません。静的解析のみを行い、検出事項と推奨事項のテキストを出力して、それを人やエージェントが別途適用します。

---

# OWASP の出典

> 組み込みの OWASP 専門知識が拠りどころとする出典を、OWASP 公式の攻撃ページと Cheat Sheet ページに対応づけて示します。

正規 URL: https://lagune.ai/ja-JP/docs/references/owasp-sources
言語: ja-JP
原文: https://lagune.ai/docs/references/owasp-sources
最終更新日: 2026-11-03

このドキュメントでは、OWASP のすべての**攻撃**（`www-community`）と **Cheat Sheet**（`CheatSheetSeries`）をセキュリティのカテゴリに対応づけ、それぞれ公式の公開ページにリンクしています。同じカテゴリ内で同等の項目は、チェックリストの 1 行にまとめています。同じリスクを扱う攻撃と Cheat Sheet は、カンマ区切りで並べています。直接対応するものがない項目は、それぞれ単独の行にしています。

- クレジットは OWASP に帰属します。攻撃のページは `https://owasp.org/www-community/attacks/<attack>`、Cheat Sheet は `https://cheatsheetseries.owasp.org/cheatsheets/<cheat>.html` にあります。

---

## 1. インジェクション（汎用）

- [x] [Code Injection](https://owasp.org/www-community/attacks/Code_Injection), [Injection Prevention](https://cheatsheetseries.owasp.org/cheatsheets/Injection_Prevention_Cheat_Sheet.html), [Injection Prevention in Java](https://cheatsheetseries.owasp.org/cheatsheets/Injection_Prevention_in_Java_Cheat_Sheet.html) (interpreter)
- [x] [Direct Dynamic Code Evaluation (Eval Injection)](https://owasp.org/www-community/attacks/Direct_Dynamic_Code_Evaluation_Eval_Injection) (interpreter)
- [x] [Function Injection](https://owasp.org/www-community/attacks/Function_Injection) (interpreter)
- [x] [Resource Injection](https://owasp.org/www-community/attacks/Resource_Injection) (network)
- [x] [Special Element Injection](https://owasp.org/www-community/attacks/Special_Element_Injection) (interpreter)
- [x] [Custom Special Character Injection](https://owasp.org/www-community/attacks/Custom_Special_Character_Injection) (interpreter)
- [x] [Comment Injection Attack](https://owasp.org/www-community/attacks/Comment_Injection_Attack) (interpreter)
- [x] [Parameter Delimiter](https://owasp.org/www-community/attacks/Parameter_Delimiter) (interpreter)
- [x] [Server-Side Includes (SSI) Injection](https://owasp.org/www-community/attacks/Server-Side_Includes_%28SSI%29_Injection) (interpreter)
- [x] [Input Validation](https://cheatsheetseries.owasp.org/cheatsheets/Input_Validation_Cheat_Sheet.html), [Bean Validation](https://cheatsheetseries.owasp.org/cheatsheets/Bean_Validation_Cheat_Sheet.html) (interpreter)

---

## 2. SQL / データベースインジェクション

- [x] [SQL Injection](https://owasp.org/www-community/attacks/SQL_Injection), [SQL Injection Prevention](https://cheatsheetseries.owasp.org/cheatsheets/SQL_Injection_Prevention_Cheat_Sheet.html), [Query Parameterization](https://cheatsheetseries.owasp.org/cheatsheets/Query_Parameterization_Cheat_Sheet.html) (sql)
- [x] [Blind SQL Injection](https://owasp.org/www-community/attacks/Blind_SQL_Injection) (sql)
- [x] [SQL Injection Bypassing WAF](https://owasp.org/www-community/attacks/SQL_Injection_Bypassing_WAF) (sql)
- [x] [RSQL Injection](https://owasp.org/www-community/attacks/RSQL_Injection) (interpreter)
- [x] [Database Security](https://cheatsheetseries.owasp.org/cheatsheets/Database_Security_Cheat_Sheet.html) (sql)
- [x] [NoSQL Security](https://cheatsheetseries.owasp.org/cheatsheets/NoSQL_Security_Cheat_Sheet.html) (interpreter)

---

## 3. OS / コマンドインジェクション

- [x] [Command Injection](https://owasp.org/www-community/attacks/Command_Injection), [OS Command Injection Defense](https://cheatsheetseries.owasp.org/cheatsheets/OS_Command_Injection_Defense_Cheat_Sheet.html) (interpreter)

---

## 4. LDAP / XPath / XML インジェクション

- [x] [LDAP Injection](https://owasp.org/www-community/attacks/LDAP_Injection), [LDAP Injection Prevention](https://cheatsheetseries.owasp.org/cheatsheets/LDAP_Injection_Prevention_Cheat_Sheet.html) (interpreter)
- [x] [XPATH Injection](https://owasp.org/www-community/attacks/XPATH_Injection) (interpreter)
- [x] [Blind XPath Injection](https://owasp.org/www-community/attacks/Blind_XPath_Injection) (interpreter)
- [x] [XML External Entity (XXE) Prevention](https://cheatsheetseries.owasp.org/cheatsheets/XML_External_Entity_Prevention_Cheat_Sheet.html), [XML Security](https://cheatsheetseries.owasp.org/cheatsheets/XML_Security_Cheat_Sheet.html) (xml)

---

## 5. クロスサイトスクリプティング（XSS）

- [x] [Cross Site Scripting (XSS)](https://owasp.org/www-community/attacks/Cross-site-Scripting-%28XSS%29), [Cross Site Scripting Prevention](https://cheatsheetseries.owasp.org/cheatsheets/Cross_Site_Scripting_Prevention_Cheat_Sheet.html), [XSS Filter Evasion](https://cheatsheetseries.owasp.org/cheatsheets/XSS_Filter_Evasion_Cheat_Sheet.html) (browser)
- [x] [DOM Based XSS](https://owasp.org/www-community/attacks/DOM_Based_XSS), [DOM based XSS Prevention](https://cheatsheetseries.owasp.org/cheatsheets/DOM_based_XSS_Prevention_Cheat_Sheet.html), [DOM Clobbering Prevention](https://cheatsheetseries.owasp.org/cheatsheets/DOM_Clobbering_Prevention_Cheat_Sheet.html) (browser)
- [x] [Reflected DOM Injection](https://owasp.org/www-community/attacks/Reflected_DOM_Injection) (browser)
- [x] [XSS in Converting File Content to Text](https://owasp.org/www-community/attacks/XSS_in_Converting_File_Content_to_Text) (browser)
- [x] [XSS in subtitle](https://owasp.org/www-community/attacks/Xss_in_subtitle) (browser)
- [x] [Cross Frame Scripting](https://owasp.org/www-community/attacks/Cross_Frame_Scripting) (browser)
- [x] [Cross Site Tracing](https://owasp.org/www-community/attacks/Cross_Site_Tracing) (browser)
- [x] [Content Security Policy](https://cheatsheetseries.owasp.org/cheatsheets/Content_Security_Policy_Cheat_Sheet.html) (browser)

---

## 6. クロスサイトリクエストフォージェリ（CSRF）とクリックジャッキング

- [x] [Cross Site Request Forgery (CSRF)](https://owasp.org/www-community/attacks/cross-site-request-forgery), [XSRF](https://owasp.org/www-community/attacks/XSRF), [Cross-Site Request Forgery Prevention](https://cheatsheetseries.owasp.org/cheatsheets/Cross-Site_Request_Forgery_Prevention_Cheat_Sheet.html) (http-request)
- [x] [Clickjacking](https://owasp.org/www-community/attacks/Clickjacking), [Clickjacking Defense](https://cheatsheetseries.owasp.org/cheatsheets/Clickjacking_Defense_Cheat_Sheet.html) (browser)
- [x] [Cross Site History Manipulation (XSHM)](https://owasp.org/www-community/attacks/Cross_Site_History_Manipulation_%28XSHM%29) (browser)
- [x] [Form action hijacking](https://owasp.org/www-community/attacks/Form_action_hijacking) (network)
- [x] [Reverse Tabnabbing](https://owasp.org/www-community/attacks/Reverse_Tabnabbing) (browser)

---

## 7. リダイレクトとフォワード

- [x] [Open Redirect](https://owasp.org/www-community/attacks/open_redirect), [Unvalidated Redirects and Forwards](https://cheatsheetseries.owasp.org/cheatsheets/Unvalidated_Redirects_and_Forwards_Cheat_Sheet.html) (network)
- [x] [Execution After Redirect (EAR)](https://owasp.org/www-community/attacks/Execution_After_Redirect_%28EAR%29) (browser)

---

## 8. アクセス制御と認可

- [x] [Insecure Direct Object Reference (IDOR)](https://owasp.org/www-community/attacks/insecure_direct_object_reference), [Insecure Direct Object Reference Prevention](https://cheatsheetseries.owasp.org/cheatsheets/Insecure_Direct_Object_Reference_Prevention_Cheat_Sheet.html) (access-control)
- [x] [Forced browsing](https://owasp.org/www-community/attacks/Forced_browsing) (access-control)
- [x] [Web Parameter Tampering](https://owasp.org/www-community/attacks/Web_Parameter_Tampering) (access-control)
- [x] [Setting Manipulation](https://owasp.org/www-community/attacks/Setting_Manipulation) (access-control)
- [x] [Authorization](https://cheatsheetseries.owasp.org/cheatsheets/Authorization_Cheat_Sheet.html) (access-control)
- [x] [Transaction Authorization](https://cheatsheetseries.owasp.org/cheatsheets/Transaction_Authorization_Cheat_Sheet.html) (access-control)
- [x] [Mass Assignment](https://cheatsheetseries.owasp.org/cheatsheets/Mass_Assignment_Cheat_Sheet.html) (access-control)
- [x] [Multi-Tenant Application Security](https://cheatsheetseries.owasp.org/cheatsheets/Multi_Tenant_Security_Cheat_Sheet.html) (access-control)

---

## 9. 認証と認証情報

- [x] [Brute Force Attack](https://owasp.org/www-community/attacks/Brute_force_attack), [Password Spraying Attack](https://owasp.org/www-community/attacks/Password_Spraying_Attack), [Bot Management and Anti-Automation](https://cheatsheetseries.owasp.org/cheatsheets/Bot_Management_and_Anti-Automation_Cheat_Sheet.html) (credential-endpoint)
- [x] [Credential stuffing](https://owasp.org/www-community/attacks/Credential_stuffing), [Credential Stuffing Prevention](https://cheatsheetseries.owasp.org/cheatsheets/Credential_Stuffing_Prevention_Cheat_Sheet.html) (credential-endpoint)
- [x] [Qrljacking](https://owasp.org/www-community/attacks/Qrljacking) (federation)
- [x] [Authentication](https://cheatsheetseries.owasp.org/cheatsheets/Authentication_Cheat_Sheet.html), [Multifactor Authentication](https://cheatsheetseries.owasp.org/cheatsheets/Multifactor_Authentication_Cheat_Sheet.html) (access-control)
- [x] [Password Storage](https://cheatsheetseries.owasp.org/cheatsheets/Password_Storage_Cheat_Sheet.html) (access-control)
- [x] [Forgot Password](https://cheatsheetseries.owasp.org/cheatsheets/Forgot_Password_Cheat_Sheet.html), [Choosing and Using Security Questions](https://cheatsheetseries.owasp.org/cheatsheets/Choosing_and_Using_Security_Questions_Cheat_Sheet.html) (access-control)
- [x] [Email Validation and Verification in Identity Systems](https://cheatsheetseries.owasp.org/cheatsheets/Email_Validation_and_Verification_Cheat_Sheet.html) (access-control)

---

## 10. セッション管理

- [x] [Session fixation](https://owasp.org/www-community/attacks/Session_fixation), [Session hijacking attack](https://owasp.org/www-community/attacks/Session_hijacking_attack), [Session Prediction](https://owasp.org/www-community/attacks/Session_Prediction), [Session Management](https://cheatsheetseries.owasp.org/cheatsheets/Session_Management_Cheat_Sheet.html) (access-control)
- [x] [Cookie Theft Mitigation](https://cheatsheetseries.owasp.org/cheatsheets/Cookie_Theft_Mitigation_Cheat_Sheet.html) (access-control)

---

## 11. ID フェデレーション（OAuth / SAML / JWT）

- [x] [OAuth 2.0 Protocol](https://cheatsheetseries.owasp.org/cheatsheets/OAuth2_Cheat_Sheet.html) (federation)
- [x] [SAML Security](https://cheatsheetseries.owasp.org/cheatsheets/SAML_Security_Cheat_Sheet.html) (federation)
- [x] [JSON Web Token for Java](https://cheatsheetseries.owasp.org/cheatsheets/JSON_Web_Token_for_Java_Cheat_Sheet.html) (federation)

---

## 12. 暗号とトランスポートセキュリティ

- [x] [Cryptanalysis](https://owasp.org/www-community/attacks/Cryptanalysis), [Cryptographic Storage](https://cheatsheetseries.owasp.org/cheatsheets/Cryptographic_Storage_Cheat_Sheet.html), [Key Management](https://cheatsheetseries.owasp.org/cheatsheets/Key_Management_Cheat_Sheet.html) (crypto)
- [x] [Manipulator-in-the-Middle (MITM)](https://owasp.org/www-community/attacks/Man-in-the-middle_attack), [Transport Layer Security](https://cheatsheetseries.owasp.org/cheatsheets/Transport_Layer_Security_Cheat_Sheet.html) (transport)
- [x] [HTTP Strict Transport Security](https://cheatsheetseries.owasp.org/cheatsheets/HTTP_Strict_Transport_Security_Cheat_Sheet.html) (transport)
- [x] [Pinning](https://cheatsheetseries.owasp.org/cheatsheets/Pinning_Cheat_Sheet.html) (transport)

---

## 13. サーバーサイドリクエストフォージェリ（SSRF）

- [x] [Server Side Request Forgery](https://owasp.org/www-community/attacks/Server_Side_Request_Forgery), [Server-Side Request Forgery Prevention](https://cheatsheetseries.owasp.org/cheatsheets/Server_Side_Request_Forgery_Prevention_Cheat_Sheet.html) (network)

---

## 14. パストラバーサルとファイル処理

- [x] [Path Traversal](https://owasp.org/www-community/attacks/Path_Traversal) (path)
- [x] [Binary Planting](https://owasp.org/www-community/attacks/Binary_planting) (path)
- [x] [Windows ::DATA Alternate Data Stream](https://owasp.org/www-community/attacks/Windows_DATA_alternate_data_stream) (path)
- [x] [Embedding Null Code](https://owasp.org/www-community/attacks/Embedding_Null_Code) (path)
- [x] [File Upload](https://cheatsheetseries.owasp.org/cheatsheets/File_Upload_Cheat_Sheet.html) (upload)

---

## 15. HTTP プロトコルの悪用（ヘッダー、キャッシュ、分割）

- [x] [HTTP Response Splitting](https://owasp.org/www-community/attacks/HTTP_Response_Splitting), [Cross-User Defacement](https://owasp.org/www-community/attacks/Cross-User_Defacement) (interpreter)
- [x] [HTTP Security Response Headers](https://cheatsheetseries.owasp.org/cheatsheets/HTTP_Headers_Cheat_Sheet.html)（browser、transport、http-request、access-control に分割）
- [x] [Cache Poisoning](https://owasp.org/www-community/attacks/Cache_Poisoning) (interpreter)
- [x] [IP Spoofing via HTTP Headers](https://owasp.org/www-community/attacks/ip_spoofing_via_http_headers) (http-request)

---

## 16. エンコーディングとコンテンツスプーフィング

- [x] [Unicode Encoding](https://owasp.org/www-community/attacks/Unicode_Encoding) (interpreter)
- [x] [Double Encoding](https://owasp.org/www-community/Double_Encoding) (interpreter)
- [x] [Content Spoofing](https://owasp.org/www-community/attacks/Content_Spoofing) (browser)

---

## 17. CSV / スプレッドシートインジェクション

- [x] [CSV Injection](https://owasp.org/www-community/attacks/CSV_Injection) (csv)

---

## 18. CORS（オリジン間リソース共有）

- [x] [CORS OriginHeaderScrutiny](https://owasp.org/www-community/attacks/CORS_OriginHeaderScrutiny) (http-request)
- [x] [CORS RequestPreflightScrutiny](https://owasp.org/www-community/attacks/CORS_RequestPreflightScrutiny) (http-request)

---

## 19. サービス拒否

- [x] [Regular expression Denial of Service (ReDoS)](https://owasp.org/www-community/attacks/Regular_expression_Denial_of_Service_-_ReDoS) (regex)

---

## 20. メモリ安全性とネイティブコード

- [x] [Buffer Overflow Attack](https://owasp.org/www-community/attacks/Buffer_overflow_attack), [Buffer Overflow via Environment Variables](https://owasp.org/www-community/attacks/Buffer_Overflow_via_Environment_Variables) (c-cpp)
- [x] [Format string attack](https://owasp.org/www-community/attacks/Format_string_attack) (c-cpp)

---

## 21. モバイルコードと信頼できないコードの実行

- [x] [Mobile code invoking untrusted mobile code](https://owasp.org/www-community/attacks/Mobile_code_invoking_untrusted_mobile_code) (interpreter)
- [x] [Mobile code non-final public field](https://owasp.org/www-community/attacks/Mobile_code_non-final_public_field) (java)
- [x] [Mobile code object hijack](https://owasp.org/www-community/attacks/Mobile_code_object_hijack) (java)

---

## 22. デシリアライゼーション

- [x] [Deserialization](https://cheatsheetseries.owasp.org/cheatsheets/Deserialization_Cheat_Sheet.html)（python、ruby、php、java、dotnet に分割）

---

## 23. マルウェアとクライアントサイドの脅威

- [x] [Man-in-the-browser attack](https://owasp.org/www-community/attacks/Man-in-the-browser_attack), [Browser Extension Security Vulnerabilities](https://cheatsheetseries.owasp.org/cheatsheets/Browser_Extension_Vulnerabilities_Cheat_Sheet.html) (browser)
- [x] [Third Party JavaScript Management](https://cheatsheetseries.owasp.org/cheatsheets/Third_Party_Javascript_Management_Cheat_Sheet.html) (browser)

---

## 24. ロギング、否認、エラー処理

- [x] [Log Injection](https://owasp.org/www-community/attacks/Log_Injection), [Logging](https://cheatsheetseries.owasp.org/cheatsheets/Logging_Cheat_Sheet.html), [Application Logging Vocabulary](https://cheatsheetseries.owasp.org/cheatsheets/Logging_Vocabulary_Cheat_Sheet.html) (interpreter)
- [x] [Repudiation Attack](https://owasp.org/www-community/attacks/Repudiation_Attack) (interpreter)

---

## 25. ビジネスロジックと機能の悪用

ビジネスロジックと機能の悪用には、攻撃対象領域ごとの専門知識が守れるような、単一のコード上の攻撃対象領域がありません。防御はアプリケーション固有の設計によるもので、プロジェクトの脅威モデリングから導かれるのと同じ考え方です。"対象外" に移しました。

---

## 26. AI / LLM / エージェントのセキュリティ

- [x] [Prompt Injection](https://owasp.org/www-community/attacks/prompt-injection), [LLM Prompt Injection Prevention](https://cheatsheetseries.owasp.org/cheatsheets/LLM_Prompt_Injection_Prevention_Cheat_Sheet.html) (llm)
- [x] [MCP Tool Poisoning](https://owasp.org/www-community/attacks/MCP_Tool_Poisoning), [MCP (Model Context Protocol) Security](https://cheatsheetseries.owasp.org/cheatsheets/MCP_Security_Cheat_Sheet.html) (llm)
- [x] [HITL Dialog Forging (Lies-in-the-Loop)](https://owasp.org/www-community/attacks/lies-in-the-loop) (llm)
- [x] [AI Agent Security](https://cheatsheetseries.owasp.org/cheatsheets/AI_Agent_Security_Cheat_Sheet.html), [Secure Coding with AI](https://cheatsheetseries.owasp.org/cheatsheets/Secure_Coding_with_AI_Cheat_Sheet.html) (llm)
- [x] [Retrieval-Augmented Generation (RAG) Security](https://cheatsheetseries.owasp.org/cheatsheets/RAG_Security_Cheat_Sheet.html) (llm)
- [x] [Secure AI/ML Model Ops](https://cheatsheetseries.owasp.org/cheatsheets/Secure_AI_Model_Ops_Cheat_Sheet.html) (llm)
- [x] [AML and Sanctions Compliance for AI Agent Payments](https://cheatsheetseries.owasp.org/cheatsheets/AML_Sanctions_AI_Agent_Payments_Cheat_Sheet.html) (llm)

---

## 27. プロトタイプ汚染とクロスサイトリーク

- [x] [Prototype Pollution Prevention](https://cheatsheetseries.owasp.org/cheatsheets/Prototype_Pollution_Prevention_Cheat_Sheet.html) (javascript)
- [x] [Cross-site leaks (XS-Leaks)](https://cheatsheetseries.owasp.org/cheatsheets/XS_Leaks_Cheat_Sheet.html) (browser)

---

## 28. フレームワークと言語プラットフォーム

- [x] [Django Security](https://cheatsheetseries.owasp.org/cheatsheets/Django_Security_Cheat_Sheet.html), [Django REST Framework](https://cheatsheetseries.owasp.org/cheatsheets/Django_REST_Framework_Cheat_Sheet.html) (python)
- [x] [Ruby on Rails](https://cheatsheetseries.owasp.org/cheatsheets/Ruby_on_Rails_Cheat_Sheet.html) (ruby)
- [x] [Laravel](https://cheatsheetseries.owasp.org/cheatsheets/Laravel_Cheat_Sheet.html) (php)
- [x] [Symfony](https://cheatsheetseries.owasp.org/cheatsheets/Symfony_Cheat_Sheet.html) (php)
- [x] [Java Security](https://cheatsheetseries.owasp.org/cheatsheets/Java_Security_Cheat_Sheet.html) (java)
- [x] [DotNet Security](https://cheatsheetseries.owasp.org/cheatsheets/DotNet_Security_Cheat_Sheet.html) (dotnet)
- [x] [NodeJS Security](https://cheatsheetseries.owasp.org/cheatsheets/Nodejs_Security_Cheat_Sheet.html) (javascript)
- [x] [PHP Configuration](https://cheatsheetseries.owasp.org/cheatsheets/PHP_Configuration_Cheat_Sheet.html) (php)

---

## 29. Web フロントエンドとブラウザー

- [x] [HTML5 Security](https://cheatsheetseries.owasp.org/cheatsheets/HTML5_Security_Cheat_Sheet.html) (browser)
- [x] [AJAX Security](https://cheatsheetseries.owasp.org/cheatsheets/AJAX_Security_Cheat_Sheet.html) (browser)
- [x] [Securing Cascading Style Sheets](https://cheatsheetseries.owasp.org/cheatsheets/Securing_Cascading_Style_Sheets_Cheat_Sheet.html)（access-control、browser に分割）

---

## 30. API とサービス

- [x] [GraphQL](https://cheatsheetseries.owasp.org/cheatsheets/GraphQL_Cheat_Sheet.html) (api-endpoint)
- [x] [gRPC Security](https://cheatsheetseries.owasp.org/cheatsheets/gRPC_Security_Cheat_Sheet.html) (api-endpoint)
- [x] [WebSocket Security](https://cheatsheetseries.owasp.org/cheatsheets/WebSocket_Security_Cheat_Sheet.html) (api-endpoint)

---

## 31. クラウド、コンテナー、インフラストラクチャ

コンテナーとワークロードの設定は、開発者がアプリと一緒にリリースする、コードとして管理された設定です（`Dockerfile`、Compose、Pod の `securityContext`）。`harden` が修正し、`verify` が証明できる実在の攻撃対象領域なので、対象に含めます。クラスター管理（RBAC、etcd、API サーバー、アドミッション制御、ネットワークセグメンテーション）は運用者の領域なので、対象外のままです。

- [x] [Docker Security](https://cheatsheetseries.owasp.org/cheatsheets/Docker_Security_Cheat_Sheet.html), [Node.js Docker](https://cheatsheetseries.owasp.org/cheatsheets/NodeJS_Docker_Cheat_Sheet.html) (container)
- [x] [Kubernetes Security](https://cheatsheetseries.owasp.org/cheatsheets/Kubernetes_Security_Cheat_Sheet.html)（container：ワークロードと Pod の部分。クラスター管理は対象外のまま）
- [x] [Serverless / FaaS Security](https://cheatsheetseries.owasp.org/cheatsheets/Serverless_FaaS_Security_Cheat_Sheet.html) (serverless)

---

## 32. サプライチェーンと CI/CD

- [x] [NPM Security](https://cheatsheetseries.owasp.org/cheatsheets/NPM_Security_Cheat_Sheet.html) (interpreter)
- [x] [Dependency Graph & SBOM Best Practices](https://cheatsheetseries.owasp.org/cheatsheets/Dependency_Graph_SBOM_Cheat_Sheet.html), [Vulnerable Dependency Management](https://cheatsheetseries.owasp.org/cheatsheets/Vulnerable_Dependency_Management_Cheat_Sheet.html) (interpreter)

---

## 33. シークレットと設定

シークレット管理は運用の領域で、保管庫、CI/CD、クラウドの設定、ローテーションが関わります。コードに関わる唯一の側面（ソースコードにハードコードされたシークレット）は決定論的なスキャンが扱うもので、リスクを扱う専門知識の対象ではありません。"対象外" に移しました。

---

## 34. プロセス、設計、ガバナンス

ユーザーのプライバシー保護はポリシーと設計の問題（データの最小化、透明性、保持期間）であり、専門知識が守るコード上の攻撃対象領域ではありません。"対象外" に移しました。

---

## 35. 決済とコンプライアンス

- [x] [Secure Integration of Third-Party Payment Gateways](https://cheatsheetseries.owasp.org/cheatsheets/Third_Party_Payment_Gateway_Integration_Cheat_Sheet.html) (payment)

---

## 36. 組み込み / IoT / 特殊な分野

自動車とドローンのセキュリティは組み込みシステムの分野（CAN バス、OTA ファームウェア、センサーと無線の完全性、物理アクセス）であり、Lagune が監査する Web アプリケーションや API のソースコードではありません。"対象外" に移しました。

---

## 対象外（コード上の攻撃対象領域なし）

ここに挙げる項目は専門知識が扱う領域ではなく、チェックボックスもありません。ガバナンス、プロセス、運用面の堅牢化、またはフレームワークの使い方に関するもので、攻撃対象領域ごとの専門知識が守れるような、単一のコード上の攻撃対象領域を持ちません。セキュリティ上の価値は確かにありますが、その価値があるのはプロセスとアーキテクチャ（フレームワークの場合は、その言語専用のスキル）であり、このカタログが提供する防御ではありません。作業項目ではなく、参考として掲載しています。

- [Authorization Regression Testing](https://cheatsheetseries.owasp.org/cheatsheets/Authorization_Regression_Testing_Cheat_Sheet.html), [Authorization Testing Automation](https://cheatsheetseries.owasp.org/cheatsheets/Authorization_Testing_Automation_Cheat_Sheet.html)
- [JAAS](https://cheatsheetseries.owasp.org/cheatsheets/JAAS_Cheat_Sheet.html)
- [Denial of Service](https://owasp.org/www-community/attacks/Denial_of_Service), [Denial of Service](https://cheatsheetseries.owasp.org/cheatsheets/Denial_of_Service_Cheat_Sheet.html)
- [HTTP/2 Reset Attack](https://owasp.org/www-community/attacks/HTTP2_Reset_Attack)
- [Traffic flood](https://owasp.org/www-community/attacks/Traffic_flood)
- [Web Service Amplification Attack](https://owasp.org/www-community/attacks/web_service_amplificaiton)（SOAP/WS-Addressing による増幅攻撃。コード上の攻撃対象領域を持たない、運用面の DoS の一種）
- [Cash Overflow](https://owasp.org/www-community/attacks/Cash_Overflow)
- [Spyware](https://owasp.org/www-community/attacks/Spyware), [Trojan Horse](https://owasp.org/www-community/attacks/Trojan_Horse)（エンドユーザー側のマルウェアで、監査対象のプロジェクトにあるコード上の攻撃対象領域ではない。ブラウザー内で届けられる側面は `browser` で扱う）
- [REST Security](https://cheatsheetseries.owasp.org/cheatsheets/REST_Security_Cheat_Sheet.html), [REST Assessment](https://cheatsheetseries.owasp.org/cheatsheets/REST_Assessment_Cheat_Sheet.html)
- [Web Service Security](https://cheatsheetseries.owasp.org/cheatsheets/Web_Service_Security_Cheat_Sheet.html)
- [Cloud Architecture Security](https://cheatsheetseries.owasp.org/cheatsheets/Secure_Cloud_Architecture_Cheat_Sheet.html)（設計とトレードオフ：IAM か署名付き URL か、パブリック VPC とプライベート VPC、信頼境界、責任共有。`container` とは違い、専門知識がチェックできる具体的な設定がない）
- [Infrastructure as Code Security](https://cheatsheetseries.owasp.org/cheatsheets/Infrastructure_as_Code_Security_Cheat_Sheet.html)（名前に反して、中身は IaC を*管理する*ための SDLC のプロセスとツール：IDE プラグイン、静的解析、イメージスキャン、CI/CD、署名。Terraform や CloudFormation のファイルについて、安全でないパターンから安全な形への書き換えは示していない）
- [Kubernetes Security](https://cheatsheetseries.owasp.org/cheatsheets/Kubernetes_Security_Cheat_Sheet.html)（_クラスター管理の部分のみ_：RBAC、etcd、API サーバー、アドミッション制御。ワークロードと Pod の部分は `container` で対象に含める）
- [Network Segmentation](https://cheatsheetseries.owasp.org/cheatsheets/Network_Segmentation_Cheat_Sheet.html)（ネットワークアーキテクチャとファイアウォールのポリシー）
- [Subdomain Takeover Prevention](https://cheatsheetseries.owasp.org/cheatsheets/Subdomain_Takeover_Prevention_Cheat_Sheet.html)（DNS のライフサイクルと監視であり、コードではない）
- [Secrets Management](https://cheatsheetseries.owasp.org/cheatsheets/Secrets_Management_Cheat_Sheet.html)（保管庫、CI/CD、ローテーション。ハードコードされたシークレットの側面は決定論的なスキャンが扱うもので、リスクを扱う専門知識の対象ではない）
- [C-Based Toolchain Hardening](https://cheatsheetseries.owasp.org/cheatsheets/C-Based_Toolchain_Hardening_Cheat_Sheet.html)（コンパイラー、リンカー、ビルドのフラグで、ソースコード上のシンクがない）
- [Microservices Security](https://cheatsheetseries.owasp.org/cheatsheets/Microservices_Security_Cheat_Sheet.html), [Microservices based Security Arch Doc](https://cheatsheetseries.owasp.org/cheatsheets/Microservices_based_Security_Arch_Doc_Cheat_Sheet.html)
- [Zero Trust Architecture](https://cheatsheetseries.owasp.org/cheatsheets/Zero_Trust_Architecture_Cheat_Sheet.html)
- [CI/CD Security](https://cheatsheetseries.owasp.org/cheatsheets/CI_CD_Security_Cheat_Sheet.html), [GitHub Actions Security](https://cheatsheetseries.owasp.org/cheatsheets/GitHub_Actions_Security_Cheat_Sheet.html)
- [Software Supply Chain Security](https://cheatsheetseries.owasp.org/cheatsheets/Software_Supply_Chain_Security_Cheat_Sheet.html)
- [Error Handling](https://cheatsheetseries.owasp.org/cheatsheets/Error_Handling_Cheat_Sheet.html), [Full Path Disclosure](https://owasp.org/www-community/attacks/Full_Path_Disclosure)（技術スタックごとのグローバルなエラーハンドラーの設定。この漏えいは、エラー処理がすでに扱っている情報開示と同じもの）
- [Abuse of Functionality](https://owasp.org/www-community/attacks/Abuse_of_Functionality), [Business Logic Security](https://cheatsheetseries.owasp.org/cheatsheets/Business_Logic_Security_Cheat_Sheet.html), [Abuse Case（_旧版_）](https://cheatsheetseries.owasp.org/cheatsheets/Abuse_Case_Cheat_Sheet.html)（アプリケーション固有の設計で、単一のコード上のシンクがない）
- [User Privacy Protection](https://cheatsheetseries.owasp.org/cheatsheets/User_Privacy_Protection_Cheat_Sheet.html)（データの最小化、透明性、保持ポリシー）
- [Top 10 Automotive Security Vulnerabilities](https://cheatsheetseries.owasp.org/cheatsheets/Automotive_Security_Cheat_Sheet.html), [Drone Security](https://cheatsheetseries.owasp.org/cheatsheets/Drone_Security_Cheat_Sheet.html)（組み込みシステムの分野：CAN バス、OTA ファームウェア、センサーや無線の完全性。Web や API のソースコードではない）
- [Mobile Application Security](https://cheatsheetseries.owasp.org/cheatsheets/Mobile_Application_Security_Cheat_Sheet.html)（Android と iOS のプラットフォームの堅牢化：ストレージ、生体認証、ピンニング、PII。単一のコード上の攻撃対象領域はなく、信頼できないコードの読み込みに関する側面は `interpreter` に移した）
- [Threat Modeling](https://cheatsheetseries.owasp.org/cheatsheets/Threat_Modeling_Cheat_Sheet.html), [Threat Modeling（_コミュニティページ_）](https://owasp.org/www-community/Threat_Modeling)
- [Attack Surface Analysis](https://cheatsheetseries.owasp.org/cheatsheets/Attack_Surface_Analysis_Cheat_Sheet.html)
- [Secure Product Design](https://cheatsheetseries.owasp.org/cheatsheets/Secure_Product_Design_Cheat_Sheet.html)
- [Secure Code Review](https://cheatsheetseries.owasp.org/cheatsheets/Secure_Code_Review_Cheat_Sheet.html)
- [Virtual Patching](https://cheatsheetseries.owasp.org/cheatsheets/Virtual_Patching_Cheat_Sheet.html)
- [Vulnerability Disclosure](https://cheatsheetseries.owasp.org/cheatsheets/Vulnerability_Disclosure_Cheat_Sheet.html)
- [Legacy Application Management](https://cheatsheetseries.owasp.org/cheatsheets/Legacy_Application_Management_Cheat_Sheet.html)
- [Security Terminology](https://cheatsheetseries.owasp.org/cheatsheets/Security_Terminology_Cheat_Sheet.html)

---

# /lagune-repair: 検出事項の壊れた追跡を修復する

> ファイル名の変更や移動で Lagune の追跡が混乱したときに、チェーンを修復します。

正規 URL: https://lagune.ai/ja-JP/docs/commands/repair
言語: ja-JP
原文: https://lagune.ai/docs/commands/repair
最終更新日: 2026-11-03

🧰 ファイル名の変更や移動でチェーンが混乱したときに、それを修復します。

**内部メンテナンス用で、セキュリティのフェーズではない**

repair は、順に進むフローの 6 番目のフェーズではありません。その役割は、追跡の整合性を保つことです。

```prompt
# 入力は受け取らず、常にチェーン全体を修復します
/lagune-repair
```

## 仕組み

detect の各検出事項は 1 つの追跡項目で、plan、harden、verify に引き継がれます。各フェーズはその項目を処理し、名前で改めて報告します。この名前はすべての成果物でまったく同じ表記のセクションタイトルとして書かれ、全体を通じてその項目の識別子になります。

追跡が保持する情報のうち、変わりうるのは項目が指すファイルパスだけです。これらのパスはほかのどこにも保存されないため、ファイル名の変更や移動で関連付けが切れるのはそこだけで、食い違う 2 つのコピーが生まれることはありません。そうなったとき、repair は追跡マップ（`.lagune/tracking.json`）を修正し、ファイル名が変わっても項目を正しく識別できるようにします。repair は成果物と追跡マップを読み、ソースコードは名前が変わったファイルの新しいパスを知るためだけに読みます。セキュリティに関する内容を書くことは決してありません。

同じ処理の中で、すべての記録をそれぞれのテンプレートと照合してずれを報告し、ずれごとに修正を担うフェーズを示します。

**ヒント**

- コードにも文章の成果物にも手を加えず、追跡だけを扱います。
- 手動で実行することはほとんどありません。チェーンの不整合に気づいたフェーズが代わりに repair を実行し、そのまま作業を続けます。
- repair が管理する追跡は `.lagune/tracking.json` にあります。手動では編集しない内部状態です。

---

# Migrate：マニフェスト方式の Lagune プロジェクトをスキルとプラグインに移行する

> マニフェスト方式の Lagune プロジェクトを、セキュリティ原則、成果物、追跡、独自の専門知識を保ったまま、スキル方式の Lagune に移行します。

正規 URL: https://lagune.ai/ja-JP/docs/commands/migrate
言語: ja-JP
原文: https://lagune.ai/docs/commands/migrate
最終更新日: 2026-11-03

🔀 マニフェスト方式の **Lagune** プロジェクトを、書いた内容をすべて保ったまま、スキル方式の **Lagune** に移行します。

**非推奨のお知らせ**

マニフェストを持つプロジェクトは、`v1.x` までは今のまま動作します。`npx lagune` が `init`、`pull`、`update`、`add`、`remove`、`list`、ダッシュボードを、マニフェスト方式の最後のバージョンである `lagune@0.15.0` に引き渡すからです。

## 移行手順

1. 現在の作業がコミット済みであることを確認してから、プロジェクトのルートで migrate を実行します：

   ```bash
   npx lagune migrate
   ```

2. migrate による変更を単独でコミットし、移行をレビューしやすい 1 つの変更にまとめます。
3. [インストールページ](https://lagune.ai/ja-JP/docs) の手順に従って、使っているエージェント向けにコマンドをインストールします。
4. プロジェクトにすでに detect、plan、harden のいずれかの成果物がある場合は、それらの成果物と独自の専門知識に残っている古い参照を照合して更新するよう、[`/lagune-repair`](https://lagune.ai/ja-JP/docs/commands/repair) に依頼します：

   ```prompt
   /lagune-repair `.lagune/memory/` 配下の成果物（`detect.md`、`plan.md`、`harden.md`）に記載されている適用済みの専門知識（旧称 sub-skills）を、新しいカタログに載っている名前と照合して更新してください。また、`.lagune/catalog/` にある自分の専門知識が `.lagune/hooks/` の古いフックを呼び出している箇所を、すべて `lagune_read` または `lagune_write` ツールの呼び出しに書き換えてください。
   ```

## 変更点

| 移行前                                                               | 移行後                                                                                         |
| -------------------------------------------------------------------- | ---------------------------------------------------------------------------------------------- |
| `.lagune/templates/`、`.lagune/hooks/`、`.lagune/specializations.md` | 削除：テンプレートは各スキルが持ち、フックはエンジンが実行する                                 |
| `.lagune/skills/` にある組み込みの専門知識のコピー                   | 削除：組み込みの専門知識はエンジンが提供する                                                   |
| `.lagune/skills/` にある独自の専門知識                               | `.lagune/catalog/` に移動                                                                      |
| `.lagune/skills.json`（独自の専門知識のインデックス）                | `.lagune/configs.json` に統合                                                                  |
| マニフェストのカテゴリ                                               | `.lagune/configs.json` に記録                                                                  |
| 旧エージェントコマンド（`/lagune.detect` など）                      | 削除：[**Lagune** をインストール](https://lagune.ai/ja-JP/docs) すると、新しいコマンド（`/lagune-detect` など）が入る |
| `.gitignore` 内の **Lagune** ブロック                                | 削除（ほかに何も書かれていなければ、ファイルごと削除）                                         |
| `.lagune/proofs/`（そのブロックで除外されていたもの）                | 専用の `.gitignore` でコミットの対象外になる                                                   |
| `.lagune/manifest.json`                                              | 最後に削除                                                                                     |

セキュリティの作業（セキュリティ原則、各フェーズが生成した成果物、各検出事項が指すパスを保持する追跡マップ）は、そのまま残ります。

## よくある質問

### 移行は必須ですか？

はい。マニフェスト方式のプロジェクトは非推奨で、v1.x までしか動作しないため、npx lagune migrate を実行して移行してください。

### migrate では何が保持されますか？

セキュリティ原則、各フェーズの成果物、追跡マップ、カテゴリ、独自の専門知識です。専門知識は .lagune/catalog/ に移動し、そのインデックスはカテゴリとともに .lagune/configs.json にまとめられます。

### 新しいコマンドはいつインストールすればよいですか？

migrate を実行したあと、インストールページで使っているエージェント向けに示されている手順に従ってインストールします。migrate は新しい /lagune を残すため、先にインストールしても問題ありません。

### チームメイトがすでに移行しました。何を実行すればよいですか？

移行の変更をプルしてから、npx lagune migrate を一度実行します。マニフェスト方式の Lagune がローカルのクローンに残したもの（バージョン管理には一度も含まれていなかったもの）を削除し、証明ファイルをコミットの対象外にします。