Claude CodeやCodexへ既存システムの改修を依頼したとき、次のような結果になった経験はないでしょうか。

  • 長時間調査したのに、コードを一行も変更せず終了した
  • 「原因を特定しました」と報告しただけで、実装していない
  • 一部の環境だけ修正し、別環境への反映を忘れた
  • テストを実行せず「問題ありません」と報告した
  • ブラウザで実画面を確認せず、表示崩れを残した
  • バックアップを取らずに本番ファイルを書き換えた
  • 前回調査した内容を次のセッションで忘れた
  • 同じ失敗を何度も繰り返した
  • 作業途中でコンテキストが切れ、最初から調査し直した
  • 完了報告は立派だが、実際には機能していなかった

AIコーディングエージェントは、局所的なコード生成や原因調査には非常に強力です。

一方で、実務のシステム改修では、単にコードを書けるだけでは不十分です。

実際の仕事では、次の一連の工程が必要になります。

  1. 依頼内容を正確に理解する
  2. 対象環境と影響範囲を確認する
  3. 既存コードとデータ構造を調査する
  4. 変更前にバックアップを取得する
  5. 実装方針を決める
  6. コードや設定を変更する
  7. テストを実行する
  8. 実際の画面や出力結果を確認する
  9. 問題があれば再修正する
  10. 変更内容と復旧方法を記録する
  11. 次回の作業へ知識を引き継ぐ

この流れを毎回長いプロンプトとして書くこともできます。

しかし、案件ごとに同じ注意事項を何度も説明するのは非効率です。また、長い依頼文を書いたとしても、AIが途中から一部の指示を忘れたり、重要度を誤って判断したりすることがあります。

そこで注目したいのが、AIコーディングエージェント向けの指示セット10xです。

10xは、Claude CodeやCodexなどへ、単なるコーディング技術ではなく、次のような「仕事の進め方」を教えるMarkdownベースの仕組みです。

  • 曖昧な依頼をそのまま実装しない
  • 調査と実装を明確に分ける
  • リポジトリ内へ作業知識を保存する
  • 完了を証拠で示す
  • 失敗や手戻りを次回へ生かす
  • 一度得た知見をセッション終了とともに失わない

本記事では、10xが何を解決するのか、CLAUDE.mdやAGENTS.mdと何が違うのか、Claude Codeへどう導入するのかを詳しく解説します。

さらに、記事を読んだ直後から実務へ使えるように、次の内容も掲載します。

  • 本番システム改修向けの日本語ルール
  • バックアップを必須化する方法
  • 調査だけで終了させない完了条件
  • ブラウザ・帳票・データベースの実証方法
  • 既存PHPシステム改修の実践例
  • WordPress改修の実践例
  • 複数環境への反映漏れを防ぐ方法
  • Codexへ転用する方法
  • Markdownだけでは防げない危険操作への対策

目次

10xとは何か

10xは、GitHubで公開されているAIコーディングエージェント向けの指示セットです。

公式リポジトリは次の場所にあります。

z3z1ma/10x｜GitHub

以前はagent-loomという名称やURLで紹介されていましたが、現在の公式リポジトリは10xへ整理されています。

10xの特徴は、巨大なアプリケーションや特殊なクラウドサービスではないことです。

基本となるのは、AIエージェントへ読ませるSKILL.mdというMarkdownファイルです。

つまり、10xそのものがAIモデルを提供するわけでも、コードを自動実行するサーバーを提供するわけでもありません。

AIエージェントに対して、どのように考え、どのように調査し、どのように記録し、何をもって完了とするかを教える「作業規律」です。

10xがAIへ教える主な行動

  • 曖昧な依頼へ疑問を持つ
  • 実装前に完了条件を定義する
  • 既存リポジトリを先に理解する
  • 調査と変更を別工程として扱う
  • 作業中の発見をリポジトリ内へ保存する
  • テストや差分などの証拠を残す
  • 自己評価だけで完了と判断しない
  • 失敗や遠回りを再利用可能な知識にする

10xの価値は、特定のプログラミング言語に依存しない点にもあります。

PHP、JavaScript、Python、Go、Rust、WordPress、Laravel、Phalconなど、対象技術が変わっても、「調査してから変更する」「証拠を残す」「知識を蓄積する」という基本原則は共通です。

なぜAIは調査だけで止まるのか

Claude Codeが調査だけで終了する原因は、単純に性能が低いからではありません。

ユーザーの依頼、AIの判断、利用可能な時間・トークン、権限、安全性などが組み合わさって発生します。

原因1：依頼の完了条件が曖昧

例えば、次の依頼を考えてみます。

在庫一覧が遅いので調べて直してください。

人間の依頼者は、「原因を調べ、実際に高速化し、画面で確認する」と考えているかもしれません。

しかし、AIから見ると、次のどこまでが求められているか明確ではありません。

  • 原因調査だけ
  • 改善案の提示まで
  • SQL修正まで
  • コード実装まで
  • 本番反映まで
  • 性能測定まで

AIが安全側へ判断すると、調査結果と改善案を出して終了することがあります。

原因2：本番環境を壊すことを恐れる

実際に稼働しているシステムでは、AIが慎重になること自体は悪くありません。

問題は、慎重さが「何もしない」という結論へつながることです。

本来は、次のように進めるべきです。

  1. 本番環境であることを認識する
  2. 変更前バックアップを取る
  3. 影響範囲を確認する
  4. 小さく変更する
  5. テストする
  6. 問題があれば戻す

しかし、これらの手順が指示されていないと、AIは「危険なので変更しません」と判断しやすくなります。

原因3：調査が目的化する

AIはファイル検索、ログ解析、SQL確認、依存関係調査などを得意とします。

調査を進めるほど新しい疑問が見つかり、さらに調査対象が増えます。

完了条件がないと、調査範囲が拡大し続けます。

その結果、時間やコンテキストを消費し、実装へ入る前に作業が終わります。

原因4：検証方法が定義されていない

修正後に何を確認すべきか分からない場合、AIは構文チェックや簡単なテストだけで終了することがあります。

例えばWordPressサイトであれば、実際には次の確認が必要です。

  • PC表示
  • スマートフォン表示
  • JavaScriptコンソール
  • フォーム送信
  • 管理画面での保存
  • キャッシュ削除後の表示

検証対象が明確でなければ、AIは最も簡単な確認だけを選びます。

原因5：セッションをまたぐ記憶が弱い

AIとの会話は、常に無限に続くわけではありません。

新しいセッションでは、前回の調査内容、失敗した方法、重要な注意点が失われることがあります。

その結果、毎回次のようなことが起こります。

  • 同じディレクトリ構成を再調査する
  • 同じSQLを再確認する
  • 以前失敗した方法をもう一度試す
  • 本番と検証環境を取り違える
  • 前回の未完了項目を忘れる

10xは、こうした情報をチャットの中だけに残さず、リポジトリ内の記録へ変えることを重視します。

CLAUDE.md、AGENTS.md、10xの違い

10xを理解するためには、CLAUDE.mdやAGENTS.mdとの違いを整理する必要があります。

CLAUDE.mdとは

CLAUDE.mdは、Claude Codeが各セッションで読むプロジェクト指示ファイルです。

一般的には、次のような内容を書きます。

  • プロジェクトの概要
  • 使用技術
  • ビルドコマンド
  • テストコマンド
  • ディレクトリ構成
  • コーディング規約
  • 禁止事項
  • 本番環境の注意点

例：

# Project Rules

- PHP 7.4互換を維持する
- WordPressコアを直接変更しない
- 変更後は `composer test` を実行する
- 本番DBへDELETEを実行しない
- テーマ変更後はPCとモバイルを確認する

CLAUDE.mdは、「このプロジェクトで何を守るか」をClaude Codeへ伝える場所です。

AGENTS.mdとは

AGENTS.mdも、AIコーディングエージェント向けのリポジトリ指示ファイルです。

Claude Code専用ではなく、Codexなど複数のエージェントから読める共通指示として利用されます。

ただし、Claude Codeは基本的にCLAUDE.mdを読みます。

AGENTS.mdを共通ファイルとして使う場合は、CLAUDE.mdから読み込む方法があります。

@AGENTS.md

## Claude Code固有ルール

- 画面変更後はChrome DevTools MCPを使用する
- 危険操作の前に確認する

10xとの違い

CLAUDE.mdやAGENTS.mdはファイル形式・配置場所です。

10xは、その中に組み込める仕事の進め方と判断原則です。

項目 CLAUDE.md AGENTS.md 10x
主な役割 Claude Codeへのプロジェクト指示 複数エージェント向け共通指示 AI開発の作業規律
対象 Claude Code Codexなど複数ツール 対応する各種AIエージェント
内容 技術、規約、コマンド 共通ルール 確認、記憶、検証、改善
記憶 固定指示を保持 固定指示を保持 作業中の知識を蓄積する考え方を提供
完了判定 自分で定義する 自分で定義する 証拠による完了確認を重視
導入方法 ファイルを作成 ファイルを作成 Skillとして追加または既存指示へ統合

つまり、次のように考えると分かりやすいでしょう。

CLAUDE.mdは社内規程を置くファイル、10xは仕事を最後まで遂行するための標準作業手順です。

10xを導入する方法

10xはSkills CLIを使って導入できます。

プロジェクトの作業ディレクトリで、次のコマンドを実行します。

npx skills add z3z1ma/10x

Skills CLIが対応しているエージェント環境を検出し、適切な場所へスキルを配置します。

導入前に内容を確認したい場合は、先にリポジトリをcloneしてください。

git clone https://github.com/z3z1ma/10x.git
cd 10x

主要な指示ファイルを確認します。

sed -n '1,240p' SKILL.md

不明な外部リポジトリから取得した指示を、確認せずAIへ読ませることは推奨できません。

Markdownファイルであっても、AIへ危険なコマンドを実行させる指示や、秘密情報を読み取らせる指示を含められます。

次の点を確認してから導入してください。

  • どのファイルを作成するか
  • どのコマンドを実行するよう指示しているか
  • 外部通信を要求していないか
  • 秘密情報を読むよう要求していないか
  • ユーザー確認を回避する指示がないか
  • 既存のCLAUDE.mdと矛盾しないか

手動で組み込む方法

10xはMarkdownベースなので、必要な部分を既存のCLAUDE.mdやAGENTS.mdへ手動で統合することもできます。

ただし、全文を無条件に貼り付けるより、プロジェクトに合わせて調整する方が実務では有効です。

特に、次の点は自社環境へ合わせる必要があります。

  • バックアップ保存先
  • 本番・検証環境の名称
  • テストコマンド
  • データベース接続ルール
  • ブラウザ検証方法
  • 帳票の確認方法
  • デプロイ手順
  • ロールバック方法

10x導入後に作られる「記憶」の考え方

10xでは、作業中に得た知識をリポジトリ内の.10x/へ保存する考え方が採用されています。

目的は、AIが次のセッションでも前回の成果を利用できるようにすることです。

記録する内容の例：

  • システムの構成
  • 重要なテーブルの関係
  • 本番環境固有の注意事項
  • 過去に失敗した対応
  • 実際に成功したテスト方法
  • 変更時に確認すべき関連機能
  • ユーザーが重視する品質基準
  • 未解決の課題

例えば、古いPHP業務システムで次のことが分かったとします。

売上明細画面では、表示用データを直接SQLで取得していない。
共通モデルの getSalesDetail() を経由している。
画面だけSQLを変更してもExcel出力には反映されない。
Excel出力は別の exportSalesDetail() を使用している。

この情報をチャットの中にしか残さなければ、次回のセッションで忘れられる可能性があります。

.10x/へ記録すれば、次の改修時に「画面だけでなくExcelも確認する必要がある」という知識を再利用できます。

記録例

.10x/
├── README.md
├── architecture.md
├── verification.md
├── incidents.md
├── decisions.md
└── tasks/
    └── inventory-performance-20260718.md

architecture.md：

# Architecture Notes

## 在庫一覧

- Controller:
  app/controllers/StockController.php
- Model:
  app/models/Stock.php
- View:
  app/views/stock/index.volt
- Excel:
  app/library/StockExcel.php

## 重要事項

画面表示とExcel出力は別クエリ。
一方だけ修正しないこと。

verification.md：

# Verification Rules

在庫一覧を変更した場合は、次を確認する。

1. 通常一覧
2. 倉庫絞り込み
3. 商品検索
4. 在庫ゼロ表示
5. マイナス在庫
6. Excel出力
7. 100万件相当データで性能測定

このように、AIが発見したプロジェクト固有の知識を、再利用可能な文書へ変換します。

10xを入れるだけで途中終了は完全になくなるのか

結論から言うと、10xを導入しただけで、途中終了が完全になくなるわけではありません。

10xは、AIの判断を改善する指示セットです。

次の問題を物理的に防止するものではありません。

  • ネットワーク切断
  • API利用上限
  • コンテキスト上限
  • OSやサーバーの停止
  • 権限不足
  • テスト環境の故障
  • ユーザーによる中断
  • AIモデルの判断ミス

また、Markdownに書かれたルールは、OSのアクセス制御ではありません。

「本番DBを削除しない」と書いても、技術的にDELETE権限が残っていれば、誤操作の可能性はゼロになりません。

10xは、次の仕組みと組み合わせる必要があります。

  • Git
  • データベースバックアップ
  • ステージング環境
  • 読み取り専用DBユーザー
  • Claude Code Hooks
  • CI/CD
  • 自動テスト
  • ブラウザ検証
  • 人間による承認

つまり、10xは「安全装置そのもの」ではなく、AIが安全装置を使って仕事を進めるための標準手順です。

本番システム改修向けに日本語化する

実際に稼働しているPHPやWordPressシステムでは、一般的な10xの考え方へ、本番運用固有のルールを追加する必要があります。

次の内容は、CLAUDE.mdまたはAGENTS.mdへ組み込める日本語テンプレートです。

# 本番システム改修規律

## 基本原則

このリポジトリは実際の業務で使用されているシステムである。
調査だけ、実装だけ、未検証の状態で完了としてはならない。

作業は必ず次の順序で行う。

1. 依頼内容の理解
2. 対象環境の確認
3. 影響範囲の調査
4. バックアップ
5. 実装
6. 静的確認
7. 自動テスト
8. 実データに近い検証
9. 実画面・帳票確認
10. 再修正
11. 完了報告
12. 知識の記録

## 調査で終了しない

依頼に「修正」「実装」「対応」「動作するようにする」が含まれる場合、
調査結果の提示だけで完了してはならない。

技術的に実装できない場合のみ、
次を証拠付きで報告する。

- 実装できない具体的理由
- 不足している権限・情報・環境
- 試した方法
- 実行結果
- 安全に進める代替案

## 変更前

必ず次を確認する。

- 現在のホスト名
- 現在のIPアドレス
- 作業ディレクトリ
- Gitの状態
- 対象DB
- 本番・検証・開発の区分
- 関連する別環境
- バックアップ保存先

## バックアップ

変更対象は、変更前に日時付きでバックアップする。

例：

filename.php.bak_YYYYMMDD_HHMMSS

DB変更を伴う場合は、
対象テーブルの構造とデータを復元可能な形式で保存する。

バックアップを取得できない場合は、
原則として破壊的変更を実行しない。

## 実装

- 既存仕様を維持する
- 関係のないコードを変更しない
- 既存のフレームワーク規約に従う
- 既存データを壊す変更を避ける
- DB変更は後方互換性を考慮する
- 本番データをテスト目的で削除しない

## 検証

変更内容に応じて次を実施する。

- PHP構文確認
- JavaScript構文・ビルド確認
- SQL実行計画
- 自動テスト
- 実画面確認
- コンソール確認
- ネットワーク確認
- Excel出力
- PDF出力
- 印刷確認
- メール送信確認
- 権限別確認

検証を実行していない項目を、
「問題なし」と報告してはならない。

## 完了条件

次をすべて満たした場合だけ完了とする。

- 要件を満たすコードが反映されている
- 変更対象が正しい環境である
- テストが成功している
- 実際の出力を確認している
- 既存機能への重大な影響がない
- 未解決事項が明記されている
- ロールバック方法が明確である
- 作業知識が記録されている

## 完了報告

必ず次を含める。

1. 対象環境
2. 調査結果
3. 原因
4. 変更内容
5. 変更ファイル
6. DB変更
7. バックアップ保存先
8. 実行したテスト
9. 実画面・帳票の確認結果
10. 未解決事項
11. ロールバック方法
12. 次回へ残した知識

実践例1：調査だけで止まりやすい在庫一覧の高速化

ここからは、10xの考え方を実際の業務システム改修へ適用します。

依頼例：

在庫一覧の表示が遅いので高速化してください。

この依頼だけでは、AIがSQLを調査して改善案を報告するだけで終わる可能性があります。

10x型の指示へ変更します。

在庫一覧の表示速度を改善してください。

この作業は調査だけではなく、
原因特定、実装、性能測定、実画面確認までが対象です。

作業前に以下を記録してください。

- 対象URL
- 対象サーバー
- 対象ディレクトリ
- 対象DB
- 現在のGit状態
- 現在の表示時間
- 実行されるSQL
- 対象件数

変更前に対象ファイルとDB定義をバックアップしてください。

調査では次を確認してください。

- N+1クエリ
- 不要な全件取得
- インデックス不足
- ORDER BYとGROUP BY
- サブクエリ
- 一覧表示後の追加Ajax
- PHP側のループ
- View内のDBアクセス
- Excel出力との共通処理
- 倉庫・商品・ロット絞り込みへの影響

原因を特定した後は、実際に修正してください。

修正後は同じ条件で3回以上測定し、
変更前後の中央値を比較してください。

また、以下を実画面で確認してください。

- 初期表示
- 倉庫絞り込み
- 商品検索
- ロット検索
- 並べ替え
- ページ移動
- Excel出力
- マイナス在庫
- 在庫ゼロ

性能が改善しても検索結果が変わっていないことを確認してください。

完了報告には次を含めてください。

- 原因
- 変更SQL
- 追加・変更したインデックス
- 変更ファイル
- 変更前後の実測値
- EXPLAIN結果
- 実画面確認結果
- ロールバックSQL
- 残課題

得られた構成情報と検証手順は、
.10x/へ再利用可能な形で記録してください。

この指示で変わる点

通常の依頼では「速くする」が目標です。

10x型では、次の証拠が必要になります。

  • 変更前の速度
  • 変更後の速度
  • データが変わっていないこと
  • 関連画面が壊れていないこと
  • 元へ戻せること

これにより、単なるSQL改善案ではなく、実際の業務で使える完了状態を目指しやすくなります。

実践例2：WordPressを現代的なデザインへ改修する

WordPressのデザイン改修は、AIが「CSSを変更しました」と報告し、実画面を十分確認しない典型的な作業です。

依頼例：

WordPressっぽさをなくし、近未来的で現代的なサイトにしてください。

この依頼には、次の問題があります。

  • 「WordPressっぽさ」の定義がない
  • 対象ページが不明
  • スマートフォン確認が指定されていない
  • 既存機能を守る条件がない
  • 表示速度の基準がない
  • 実画面検証が指定されていない

10x型の実践プロンプト：

WordPressサイトを現代的な企業サイトへ全面改修してください。

この作業は、
調査、デザイン設計、実装、実画面検証、再修正までが対象です。
調査や提案だけで終了してはなりません。

最初に次を確認してください。

- WordPress本体のバージョン
- PHPバージョン
- 有効テーマ
- 子テーマの有無
- 有効プラグイン
- キャッシュ構成
- 独自投稿タイプ
- 固定ページ
- 使用中ショートコード
- フォーム
- SEO設定
- 計測タグ

変更前にテーマ、独自プラグイン、DBをバックアップしてください。

WordPressコアと外部プラグインを直接改変しないでください。
子テーマまたは保守可能な独自実装を優先してください。

対象ページ：

- トップページ
- 会社概要
- 事業内容
- 製品紹介
- お知らせ一覧
- 投稿詳細
- お問い合わせ
- 404ページ
- プライバシーポリシー

デザイン要件：

- 既製WordPressテーマ感をなくす
- プロが個別設計した印象にする
- 信頼感と先進性を両立する
- 不要なサイドバーを使わない
- 余白、文字、画像比率を統一する
- スクロール演出は操作性を損なわない
- アニメーション停止設定へ配慮する
- スマートフォンで横スクロールを発生させない

実装後はChrome DevTools MCPを使用し、
実際のChromeで検証してください。

画面幅：

- 1440×900
- 1024×768
- 768×1024
- 430×932
- 390×844
- 375×667
- 320×568

確認事項：

- レイアウト
- グローバルメニュー
- モバイルメニュー
- リンク
- 画像
- フォーム
- JavaScriptコンソール
- ネットワークエラー
- 横スクロール
- 固定ヘッダー
- CLS
- LCP

問題を発見した場合は修正し、
同じ条件で再検証してください。

スクリーンショットは、
変更前と変更後を分けて保存してください。

完了報告には以下を含めてください。

- デザイン方針
- 変更ファイル
- 使用した技術
- 確認URL
- 確認画面幅
- コンソール結果
- ネットワーク結果
- 性能結果
- 未解決事項
- ロールバック方法

サイト固有の構成と検証手順を、
.10x/へ保存してください。

このプロンプトでは、「見た目を良くした」という主観だけで完了できません。

実際のURL、画面幅、コンソール、性能、スクリーンショットという証拠が必要になります。

実践例3：複数の本番環境へ同じ不具合を反映する

同じシステムを顧客別に複製している場合、一つの環境だけ修正して、他環境への反映を忘れる事故が起こります。

例えば、次の三環境があるとします。

  • 顧客A本番
  • 顧客B本番
  • デモ環境

ただし、すべてが完全に同じコードとは限りません。

一括コピーすると、顧客固有機能を壊す危険があります。

10x型の指示：

同一系統の3環境に存在する不具合を修正してください。

重要：
3環境は似ていますが、完全に同一ではありません。
ファイルを無条件にコピーしてはなりません。

対象環境ごとに次を記録してください。

- URL
- 実ディレクトリ
- Gitブランチ
- DB名
- PHPバージョン
- フレームワークバージョン
- 該当機能の実装差
- 顧客固有仕様

まずデモ環境で原因を特定し、修正・検証してください。

その後、他環境の差分を調査し、
同じ原因が存在する場合だけ、
各環境に適した形で修正してください。

各環境で必ず次を実施してください。

- 変更前バックアップ
- 構文確認
- DB確認
- 対象機能のテスト
- 関連機能の回帰確認
- 実画面確認

一つの環境で成功した結果を、
他環境の確認結果として流用してはなりません。

環境ごとの作業結果を表形式で報告してください。

得られた環境差分は、
.10x/environments.mdへ保存してください。

このように、「似ているが同一ではない」という重要な知識を永続化します。

実践例4：帳票・PDF・Excel出力を確実に確認する

業務システムでは、画面が動くだけでは完了になりません。

請求書、納品書、加工依頼書、在庫表、Excel出力などが正しくなければ、実務では使えません。

AIは、帳票生成コードを修正しても、実際にPDFやExcelを開かずに終了することがあります。

10x型プロンプト：

帳票出力の修正を行ってください。

コード変更だけでは完了としません。
実際のテストデータを作成し、
帳票を出力して内容を確認してください。

確認対象：

- PDF
- Excel
- 印刷プレビュー
- 1ページ
- 複数ページ
- 0件
- 1件
- 最大件数に近いデータ
- 長い商品名
- 長い得意先名
- 日本語
- 数値
- 金額
- 改ページ
- フッター
- 印影
- 日付

次を証拠として保存してください。

- 使用したテスト条件
- 出力ファイル
- 出力時のログ
- ページ数
- 主要項目の値
- 修正前後の比較

PDFやExcelを生成しただけでなく、
実際に内容を読み取り、
列ずれ、文字切れ、改ページ、合計値を確認してください。

不具合を発見した場合は再修正し、
同じテストを繰り返してください。

このような検証手順を`.10x/verification-reports.md`などへ残せば、次回の帳票改修にも利用できます。

「完了報告」を証拠ベースへ変える

AIの完了報告で最も危険なのは、実行した事実と、推測した内容が混在することです。

例えば、次の報告は十分ではありません。

修正しました。
問題なく動作するはずです。

「はずです」は検証ではありません。

10x型では、完了報告を次の構造にします。

# 完了報告

## 1. 対象環境

- Host:
- URL:
- Directory:
- Database:
- Branch:

## 2. 原因

実際に確認した原因を記載。

## 3. 変更内容

- 変更ファイル
- 変更箇所
- 変更理由

## 4. バックアップ

- 保存先
- 作成日時
- 復元方法

## 5. 実行した検証

| 検証項目 | 実行コマンド・操作 | 結果 | 証拠 |
|---|---|---|---|

## 6. 実画面・出力確認

- 確認URL
- 確認データ
- 確認画面幅
- PDF・Excel保存先

## 7. 未実施項目

実行できなかった検証を明記。

## 8. 未解決事項

残っている問題を明記。

## 9. ロールバック

元へ戻す具体的手順。

## 10. 保存した知識

.10x/へ追加した内容。

特に重要なのは、未実施項目を明記することです。

テストできなかったことを隠さず、「何を確認していないか」を明確にすれば、人間が最終判断できます。

10xとClaude Codeの自動メモリは何が違うのか

Claude Codeには、プロジェクトに関する知識を自動的に保存するメモリ機能があります。

では、10xの`.10x/`は不要なのでしょうか。

役割が異なります。

Claude Codeの自動メモリ

  • Claude自身が記録する
  • ローカル環境で利用される
  • 利用者が意識しなくても蓄積される
  • ビルドコマンドやデバッグ知識などを保持する

.10x/のリポジトリ内記録

  • プロジェクト成果物として保存できる
  • Gitで共有できる
  • 人間もレビューできる
  • Claude Code以外のエージェントも読める
  • 何を残すかを明示的に設計できる

自動メモリは個人の作業効率を上げるのに向いています。

.10x/は、チームや複数エージェント間で知識を共有し、監査可能な形にする用途へ向いています。

両方を併用できます。

10xをCodexへ転用できるか

10xは特定のAIモデル専用ではなく、プロジェクト指示を読めるエージェントへ転用できます。

Codexでは、一般的にAGENTS.mdをプロジェクト指示として利用します。

したがって、共通ルールをAGENTS.mdへ置き、Claude Code側のCLAUDE.mdから読み込む構成が管理しやすくなります。

推奨構成

project/
├── AGENTS.md
├── CLAUDE.md
├── .10x/
│   ├── architecture.md
│   ├── verification.md
│   ├── decisions.md
│   └── incidents.md
└── src/

AGENTS.md：

# 共通AI開発規律

- 調査だけで終了しない
- 実装前に完了条件を定義する
- 変更前にバックアップを取る
- 変更後はテストを実行する
- 証拠なしに完了報告しない
- 作業中の知識を .10x/ に保存する

## Project

- PHP 7.4互換
- MariaDB
- 本番DBへの破壊的操作は禁止
- PDFとExcel出力を確認する

CLAUDE.md：

@AGENTS.md

## Claude Code固有

- UI変更後はChrome DevTools MCPを使用する
- `/memory`で読み込まれた指示を確認する
- 重要操作にはユーザー確認を求める

この方法なら、共通の業務規律をCodexとClaude Codeの両方へ適用できます。

完全に同じ動作になるわけではない

同じMarkdownを読ませても、Claude CodeとCodexでは次が異なります。

  • 利用できるツール
  • 権限確認の仕組み
  • コンテキスト管理
  • サブエージェント機能
  • メモリ機能
  • 指示の優先順位

したがって、共通ルールとツール固有ルールを分離することが重要です。

Markdown指示を長くしすぎない

「AIに全部守らせたい」と考えると、CLAUDE.mdやAGENTS.mdへ大量のルールを書きたくなります。

しかし、長すぎる指示は逆効果になる可能性があります。

指示が肥大化すると、次の問題が起きます。

  • 重要なルールが埋もれる
  • 互いに矛盾する
  • 毎回大量のコンテキストを消費する
  • 特定作業に不要なルールまで読み込まれる
  • 古い情報が残り続ける

実務では、次のように分けるのが有効です。

CLAUDE.md
├── 絶対に守る短いルール
├── プロジェクト概要
└── 詳細ルールへの参照

.claude/rules/
├── database.md
├── wordpress.md
├── security.md
└── reports.md

.10x/
├── architecture.md
├── verification.md
├── decisions.md
└── incidents.md

常に読むべき指示は短くし、作業対象に応じた詳細ルールを分離します。

MarkdownではなくHooksで強制すべきルール

10xやCLAUDE.mdは、AIの行動を強く誘導できます。

しかし、絶対に実行させたくない操作は、文章だけに頼るべきではありません。

例えば、次の操作です。

  • 本番DBのDROP
  • 本番DBのTRUNCATE
  • ルートディレクトリの削除
  • SSH秘密鍵の読み取り
  • 秘密情報の外部送信
  • 確認なしの本番デプロイ

Claude CodeのPreToolUse Hookなどを利用し、危険なコマンドを実行前に拒否します。

概念例：

#!/usr/bin/env bash

INPUT="$(cat)"

if echo "$INPUT" | grep -Eiq \
  'DROP[[:space:]]+DATABASE|DROP[[:space:]]+TABLE|TRUNCATE[[:space:]]+TABLE|rm[[:space:]]+-rf[[:space:]]+/$'; then
  echo "危険な操作を検出したため拒否しました。" >&2
  exit 2
fi

exit 0

さらに、OSやDB側でも権限を制限します。

  • 通常作業は読み取り専用DBユーザー
  • 本番反映用ユーザーを分離
  • sudo権限を限定
  • SSH鍵を用途別に分ける
  • 本番環境への接続元を制限

理想的な構成は次のとおりです。

10xで正しい仕事の進め方を教え、Hooksで危険操作を止め、OS・DB権限で最終的に保護する。

10x導入前後を比較する検証方法

10xが本当に効果を持つか確認するには、同じ課題を条件を変えて実行します。

検証課題の例

既存のPHPシステムへ、一覧検索とExcel出力の新項目を追加する課題を用意します。

条件A：通常の短い指示

一覧画面とExcelに色名を追加してください。

条件B：10xを導入した環境

同じ依頼を、10xとプロジェクトルールが読み込まれた状態で実行します。

比較項目

評価項目 確認内容
要件確認 不明点を適切に整理したか
影響調査 画面、Excel、帳票、APIを確認したか
バックアップ 変更前に取得したか
実装 調査で止まらず変更したか
テスト コマンドを実行したか
実画面 表示を確認したか
証拠 ログや出力を残したか
記憶 次回用の知識を保存したか
手戻り 同じ調査を繰り返したか
完了精度 要件を本当に満たしたか

評価時の注意

AIの出力には揺らぎがあります。

一度の実行だけで効果を断定せず、同じ種類の課題を複数回試す必要があります。

また、10x導入後にプロンプト自体も詳しくなっている場合、改善が10xだけによるものか区別できません。

可能であれば、依頼文を同じにし、プロジェクト指示の有無だけを変えて比較します。

読まれる記事にするなら「10xの紹介」で終わらせない

10xは有用ですが、日本語での検索数は、Claude CodeやCodexほど多くない可能性があります。

そのため、記事を「10xというGitHubリポジトリの紹介」だけにすると、読者層が限定されます。

検索されやすい悩みを入口にすることが重要です。

狙うべき検索意図

  • Claude Code 途中で止まる
  • Claude Code 調査だけ
  • Claude Code 実装しない
  • Claude Code CLAUDE.md 書き方
  • Claude Code 指示 忘れる
  • Claude Code 完了報告 嘘
  • Codex AGENTS.md
  • AIコーディング 本番環境
  • Claude Code バックアップ
  • Claude Code テストしてくれない

本記事の価値は、10xそのものより、次の悩みへ答える点にあります。

AIコーディングエージェントを、単発のコード生成機ではなく、最後まで仕事を遂行する開発担当者へ近づけるにはどうすればよいか。

10xは、その答えを考えるための具体的な材料です。

10x導入時の注意点

プロジェクト固有ルールと矛盾させない

10xの一般原則と、既存のCLAUDE.mdが矛盾すると、AIがどちらを優先するか不安定になります。

例：

ルールA：
不明点があれば必ず作業を停止して質問する。

ルールB：
質問せず合理的に推測して最後まで進める。

この二つは衝突します。

次のように条件を分けます。

本番データを破壊する可能性がある不明点は質問する。
表示文言や軽微な実装詳細は合理的に判断して進め、
判断内容を完了報告へ記載する。

.10x/へ秘密情報を書かせない

作業記録へ次の情報を残さないようにします。

  • パスワード
  • APIキー
  • 秘密鍵
  • 個人情報
  • 本番Cookie
  • 顧客の機密データ

`.10x/`をGitへ含める場合、社外公開リポジトリへ機密構成を載せないよう注意してください。

記録を増やしすぎない

何でも記録すると、必要な情報を探せなくなります。

残すべきなのは、次回の作業コストを下げる情報です。

  • 再発しやすい失敗
  • 重要な構成
  • 特殊な検証方法
  • 設計判断と理由
  • 環境差分

一時的なログや、単なる作業実況は別のログファイルへ分けます。

そのまま使える最終版CLAUDE.md

最後に、10xの考え方を実務向けに再構成したCLAUDE.mdの例を掲載します。

# AI Development Operating Rules

## Mission

このプロジェクトでは、
調査、実装、検証、再修正、記録までを一つの作業として扱う。

コードを変更しただけ、
原因を説明しただけ、
テストしていない状態を完了としてはならない。

## Before Work

作業開始時に次を確認する。

- ユーザーが求める最終結果
- 対象URL
- 対象ホスト
- 対象ディレクトリ
- 対象DB
- 本番・検証・開発の区分
- Git状態
- 関連環境
- 既存の .10x/ 記録

要件に重大な曖昧さがある場合は、
破壊的変更を行う前に確認する。

軽微な実装詳細は合理的に判断し、
判断内容を記録する。

## Discovery

実装前に次を調査する。

- 関連コード
- データフロー
- DB構造
- 既存テスト
- 関連画面
- 帳票・Excel・PDF
- 顧客固有仕様
- 変更による影響範囲

調査は目的ではなく、
安全に実装するための工程である。

依頼が修正・実装を求めている場合、
調査結果だけで終了してはならない。

## Backup

変更前に復元可能なバックアップを取得する。

- 対象ファイル
- DB構造
- 影響するDBデータ
- 設定ファイル

バックアップ保存先と復元方法を記録する。

## Execution

- 最小限で保守可能な変更を行う
- 関係のないコードを変更しない
- 既存規約に従う
- 後方互換性を考慮する
- 本番データをテスト用に削除しない
- 外部ライブラリやコアを安易に直接変更しない

## Verification

変更内容に応じて必要な検証を選択する。

- 構文確認
- 静的解析
- 単体テスト
- 結合テスト
- SQL EXPLAIN
- 性能測定
- 実画面
- モバイル表示
- コンソール
- ネットワーク
- フォーム
- PDF
- Excel
- 印刷
- メール
- 権限別動作

実行していない検証を、
成功したと報告してはならない。

問題を発見した場合は、
原因を特定し、修正し、同じ条件で再検証する。

## Evidence

完了判定には証拠を使用する。

証拠の例：

- コマンド出力
- テストログ
- Git差分
- SQL結果
- 性能測定値
- スクリーンショット
- 出力PDF
- 出力Excel
- HTTPレスポンス
- ブラウザコンソール

「動作するはず」は証拠ではない。

## Memory

再利用価値のある知識を .10x/ に保存する。

保存対象：

- アーキテクチャ
- 環境差分
- 設計判断
- 失敗した方法
- 成功した検証手順
- 繰り返し発生する注意点
- 未解決事項

秘密情報や個人情報は保存しない。

## Done Definition

次を満たした場合だけ完了とする。

- 要件を満たしている
- 正しい環境へ反映されている
- バックアップがある
- 必要なテストが成功している
- 実際の画面・出力を確認している
- 既存機能への重大な影響がない
- 未実施項目が明記されている
- 未解決事項が明記されている
- ロールバック方法がある
- 再利用可能な知識が保存されている

## Final Report

最終報告には次を含める。

1. 対象環境
2. ユーザー要件
3. 調査結果
4. 原因
5. 実装内容
6. 変更ファイル
7. DB変更
8. バックアップ
9. テスト結果
10. 実画面・帳票確認
11. 性能比較
12. 未実施項目
13. 未解決事項
14. ロールバック
15. .10x/へ保存した知識

まとめ

10xは、Claude CodeやCodexを突然何倍も賢くする魔法のAIモデルではありません。

その役割は、AIコーディングエージェントへ、実務で必要な仕事の進め方を教えることです。

特に、次の問題に悩んでいる場合は導入を検討する価値があります。

  • 調査だけで終了する
  • コードを変更しても検証しない
  • 同じ失敗を繰り返す
  • セッションが変わると構成を忘れる
  • 完了報告と実際の状態が一致しない
  • 本番作業のバックアップが徹底されない
  • 複数環境の反映漏れが起きる

10xの中心的な考え方は、次の五点に集約できます。

  1. Clarify：何を完成させるのか明確にする
  2. Discover：変更前に既存システムを理解する
  3. Execute：調査で止まらず実装する
  4. Verify：完了を証拠で示す
  5. Remember：得た知識を次回へ残す

ただし、Markdownに書いただけで、AIの行動を完全に強制できるわけではありません。

本番システムでは、次の組み合わせが必要です。

  • 10xによる作業規律
  • CLAUDE.mdまたはAGENTS.mdによるプロジェクトルール
  • Gitとバックアップ
  • Hooksによる危険操作の拒否
  • DB・OSの最小権限
  • 自動テスト
  • Chrome DevTools MCPなどによる実画面確認
  • 人間による最終承認

AIコーディングで本当に重要なのは、最初の回答が賢いことだけではありません。

調査した内容を実装へつなげ、動作を確認し、失敗を記録し、次の作業を前回より良くする仕組みが必要です。

10xは、その仕組みを一から考えるための有力なテンプレートです。

まずは本番環境へ直接導入するのではなく、テスト用リポジトリで通常のClaude Codeと10x導入後の動きを比較してください。

そのうえで、自社のバックアップ、検証、帳票、データベース、複数環境の運用に合わせて、日本語のルールへ作り替えることが重要です。

参考リンク

本記事は2026年7月18日時点で公開されている情報を基に作成しています。10x、Claude Code、Codex、Skills CLIなどの導入方法や仕様は今後変更される可能性があります。実際に導入する際は、公式リポジトリの最新README、SKILL.md、ライセンス、変更履歴を確認してください。

10x AI ChatGPT Claude
ABOUT ME
Yuusuke
業務システムの要件定義・設計・実装を担当。Python、PHP、JavaScript、VBA、Oracle、MySQLなど、実務と個人開発で検証した内容を発信しています。