Codex CLI エージェント運用方針（scpln）

本ドキュメントは、本リポジトリにおける Codex CLI エージェント（以下「エージェント」）の振る舞い・権限・開発フローを定義します。効率的かつ安全に、継続的な改善と自動化を推進するための実務ガイドです。

目的

サプライチェーン計画シミュレーション（SCM/Logistics/S&OP/OR領域）に関する開発・保守・ドキュメント整備を、エージェント主導で高速化する。
リポジトリ直下配備の規約に従い、人的承認なしに必要作業（ファイル編集・コミット・プッシュ・PR作成）を完遂する。

知識前提

一般的・標準的な SCM・Logistics・S&OP・OR（オペレーションズリサーチ）の基礎知識を有する前提で意思決定・提案を行う。
- 例: 需要伝播、在庫ポジション、サービスレベル、MOQ/発注倍数、キャパシティ制約、BOMと材料消費、PL指標など。

言語・出力スタイル

すべて日本語で応答する（コメント、コミットメッセージ、PR本文、ログ的な説明含む）。
可能な限り簡潔・具体・実務的に。箇条書きを多用し、冗長な前置きを避ける。
思考の開示方針: 内部の逐語的思考過程は出力せず、代わりに「要約された理由・方針・代替案」を簡潔に提示する（セキュリティ・プライバシー観点）。
実行前プレアンブル: 1–2文の短い説明（何を・なぜ）を付与。
```
update_plan
```
を用いた短いタスク計画を維持（常に1つが in_progress）。

権限と操作ポリシー

リポジトリルート以下でのファイル作成・更新・削除を許可（都度許可不要）。
Git 操作（ブランチ作成、コミット、プッシュ、PR作成）を許可（都度許可不要）。
Codex CLI ツール使用指針:
- ファイル編集は必ず
```
apply_patch
```
  を使用（手作業コピーは不可）。
- Python関連の作業では
```
.venv/
```
  配下の仮想環境を必ず利用し、依存関係をグローバルに導入しない。
- シェル実行は必要最小限。ネットワーク要否/書込要否に応じ
```
with_escalated_permissions: true
```
  を付け、ユーザー確認なしで自動実行を試みる。
- 失敗時はエラーログを添えて一度だけ再試行し、それでも不可の場合は代替経路を提示。

開発フロー（標準）

計画:
```
update_plan
```
で非自明な作業だけを短文で管理。ステップ完了ごとに更新。
実装: 影響範囲を最小化し、根本原因を修正。無関連なリファクタはしない。
テスト: 変更箇所に近い単位から段階的に確認。テストやビルドが存在する場合は活用。
フォーマット: 既存のフォーマッタ/規約があればそれに合わせる（対象ファイル限定で実行）。
変更説明: 完了時は簡潔な差分要約・影響範囲・次アクションを提示。

AI-CLI テスト手順

pytest等を実行する前に

PYTHONPATH=. .venv/bin/python scripts/prepare_test_db_template.py

を実行し、

tmp/alembic_template/template.db

を常に最新化する。

上記テンプレートが存在する場合、
```
tests/conftest.py
```
が自動で流用するため、120秒制限下でもAlembicマイグレーション待ちを発生させない。
テンプレート生成に失敗した場合はエラーログを記録し、再度1回だけ同コマンドを試行。それでも不可の場合は代替案（小規模テストのみ実行など）を提示する。

Git 運用規約

直接
```
main
```
へコミット/プッシュ可。大規模変更や衝突リスクがある場合はトピックブランチを切る。
- ブランチ例:
```
feat/xxxx-ja
```
  ,
```
fix/xxxx-ja
```
  ,
```
docs/xxxx-ja
```
コミットメッセージは Conventional Commits を日本語で準拠:
```
feat: ...
```
,
```
fix: ...
```
,
```
docs: ...
```
,
```
refactor: ...
```
,
```
chore: ...
```
,
```
test: ...
```
PR は必要に応じて作成（自動マージ方針可）。PR 説明には目的・要点・確認観点を簡潔に列挙。

PR 自動マージ運用（必須）

原則: すべてのPRは作成直後に「自動マージ（Auto-merge）」を有効化する。
- 既定のマージ方式は
```
squash
```
  を用いる。

実行手順（例）:

PR作成:

gh pr create --base main --head <feature-branch> --title "..." --body-file <file>

自動マージ有効化:

gh pr merge --auto --squash <PR番号 or ブランチ>

ブランチ保護でレビュー必須の場合:
- 自動マージを設定した上で、必要レビュアを割当（例:
```
gh pr edit <PR番号> --add-reviewer <user>
```
  ）。
- すべての必須チェック/レビューが揃い次第、自動的にマージされる。
失敗時の扱い:
- ```
--auto
```
  が拒否された場合は、原因（権限/設定）をPRにコメントし、手動承認フローへ切替。
- CI失敗・コンフリクト時は修正コミットをプッシュし、再度
```
--auto
```
  を設定。
マージ後の後始末:
- マージ時に
```
--delete-branch
```
  を併用し、トピックブランチを削除する。

ドキュメント方針

README はユーザー視点の入口として最新化。仕様やモデル構造・API・計算ロジックの要点を簡潔に。
README および
```
docs/
```
配下のドキュメントは、英語版と日本語版を同時に更新し整合性を維持することを優先する。
Mermaid 図は GitHub 互換構文を厳守。
- graph: セミコロン・シンプルラベル・最小限のエッジラベル。
- sequence:
```
actor
```
  /
```
participant
```
  を用い、記号や括弧を避け、英数字とスペース中心。
大きな追記は見出し単位で、関連セクションの前後に配置し整合を取る。

実装ガイド

既存スタイルを尊重し、命名・構造・ファイル配置を踏襲。
仕様修正時は周辺コードへの副作用を把握し、必要な最小のインタフェース変更に留める。
入出力スキーマ変更時は必ず README と例（サンプル JSON）を更新。
例外処理・ログは過不足なく。過度な詳細ログや秘密情報は出力しない。

変更の検証

可能であればローカルでの最小限の実行確認（ユニット/スモーク）。
直接確認できない場合は、検証手順（コマンド/URL/想定出力）を README か PR に記載。

エラー処理・再試行

コマンド失敗時は、原因（権限・ネットワーク・依存関係）を短く診断し代替案を提示。
破壊的操作（削除・リセット）は原則回避。やむを得ない場合はバックアップパスを先に提示し、工程化の上で実行。

セキュリティ・秘匿

シークレット/個人情報/資格情報はコミット禁止。
```
.env
```
や鍵類は扱わない。
機密に該当し得る思考の逐語展開は避け、要約（意図・根拠・選択肢）に留める。

サンプル応答テンプレート

進行中（プレアンブル）: 「次にXを行います。Yの前提を確認済みです。」
変更完了: 「Xを追加/修正しました。主な変更: A/B/C。影響: D。必要ならEを続けます。」
失敗/代替: 「Xで失敗（理由Y）。代替としてA/Bを提案します。」

付録: よく使うコマンド／ツール呼び出し（方針）

ファイル編集:
```
apply_patch
```
を単一の論理変更単位で実行。
ステージ/コミット/プッシュ: 作業完了ごとに小さく分け、件名先頭に種別を明示。
計画更新: ステップ完了のたびに
```
update_plan
```
。計画の変更時は短い説明を添付。

本規約により、エージェントは追加の都度承認なく、リポジトリ内での作業（ファイル操作・コミット・プッシュ・PR）を実施します。人手確認が望ましい場面（仕様破壊・広範囲変更など）では PR を作成し、要点を日本語で明記します。

Codex CLI エージェント運用方針（scpln）

目的

サプライチェーン計画シミュレーション（SCM/Logistics/S&OP/OR領域）に関する開発・保守・ドキュメント整備を、エージェント主導で高速化する。
リポジトリ直下配備の規約に従い、人的承認なしに必要作業（ファイル編集・コミット・プッシュ・PR作成）を完遂する。

知識前提

一般的・標準的な SCM・Logistics・S&OP・OR（オペレーションズリサーチ）の基礎知識を有する前提で意思決定・提案を行う。
- 例: 需要伝播、在庫ポジション、サービスレベル、MOQ/発注倍数、キャパシティ制約、BOMと材料消費、PL指標など。

言語・出力スタイル

すべて日本語で応答する（コメント、コミットメッセージ、PR本文、ログ的な説明含む）。
可能な限り簡潔・具体・実務的に。箇条書きを多用し、冗長な前置きを避ける。
思考の開示方針: 内部の逐語的思考過程は出力せず、代わりに「要約された理由・方針・代替案」を簡潔に提示する（セキュリティ・プライバシー観点）。
実行前プレアンブル: 1–2文の短い説明（何を・なぜ）を付与。
```
update_plan
```
を用いた短いタスク計画を維持（常に1つが in_progress）。

権限と操作ポリシー

リポジトリルート以下でのファイル作成・更新・削除を許可（都度許可不要）。
Git 操作（ブランチ作成、コミット、プッシュ、PR作成）を許可（都度許可不要）。
Codex CLI ツール使用指針:
- ファイル編集は必ず
```
apply_patch
```
  を使用（手作業コピーは不可）。
- Python関連の作業では
```
.venv/
```
  配下の仮想環境を必ず利用し、依存関係をグローバルに導入しない。
- シェル実行は必要最小限。ネットワーク要否/書込要否に応じ
```
with_escalated_permissions: true
```
  を付け、ユーザー確認なしで自動実行を試みる。
- 失敗時はエラーログを添えて一度だけ再試行し、それでも不可の場合は代替経路を提示。

開発フロー（標準）

計画:
```
update_plan
```
で非自明な作業だけを短文で管理。ステップ完了ごとに更新。
実装: 影響範囲を最小化し、根本原因を修正。無関連なリファクタはしない。
テスト: 変更箇所に近い単位から段階的に確認。テストやビルドが存在する場合は活用。
フォーマット: 既存のフォーマッタ/規約があればそれに合わせる（対象ファイル限定で実行）。
変更説明: 完了時は簡潔な差分要約・影響範囲・次アクションを提示。

AI-CLI テスト手順

pytest等を実行する前に

PYTHONPATH=. .venv/bin/python scripts/prepare_test_db_template.py

を実行し、

tmp/alembic_template/template.db

を常に最新化する。

上記テンプレートが存在する場合、
```
tests/conftest.py
```
が自動で流用するため、120秒制限下でもAlembicマイグレーション待ちを発生させない。
テンプレート生成に失敗した場合はエラーログを記録し、再度1回だけ同コマンドを試行。それでも不可の場合は代替案（小規模テストのみ実行など）を提示する。

Git 運用規約

直接
```
main
```
へコミット/プッシュ可。大規模変更や衝突リスクがある場合はトピックブランチを切る。
- ブランチ例:
```
feat/xxxx-ja
```
  ,
```
fix/xxxx-ja
```
  ,
```
docs/xxxx-ja
```
コミットメッセージは Conventional Commits を日本語で準拠:
```
feat: ...
```
,
```
fix: ...
```
,
```
docs: ...
```
,
```
refactor: ...
```
,
```
chore: ...
```
,
```
test: ...
```
PR は必要に応じて作成（自動マージ方針可）。PR 説明には目的・要点・確認観点を簡潔に列挙。

PR 自動マージ運用（必須）

原則: すべてのPRは作成直後に「自動マージ（Auto-merge）」を有効化する。
- 既定のマージ方式は
```
squash
```
  を用いる。

実行手順（例）:

PR作成:

gh pr create --base main --head <feature-branch> --title "..." --body-file <file>

自動マージ有効化:

gh pr merge --auto --squash <PR番号 or ブランチ>

ブランチ保護でレビュー必須の場合:
- 自動マージを設定した上で、必要レビュアを割当（例:
```
gh pr edit <PR番号> --add-reviewer <user>
```
  ）。
- すべての必須チェック/レビューが揃い次第、自動的にマージされる。
失敗時の扱い:
- ```
--auto
```
  が拒否された場合は、原因（権限/設定）をPRにコメントし、手動承認フローへ切替。
- CI失敗・コンフリクト時は修正コミットをプッシュし、再度
```
--auto
```
  を設定。
マージ後の後始末:
- マージ時に
```
--delete-branch
```
  を併用し、トピックブランチを削除する。

ドキュメント方針

README はユーザー視点の入口として最新化。仕様やモデル構造・API・計算ロジックの要点を簡潔に。
README および
```
docs/
```
配下のドキュメントは、英語版と日本語版を同時に更新し整合性を維持することを優先する。
Mermaid 図は GitHub 互換構文を厳守。
- graph: セミコロン・シンプルラベル・最小限のエッジラベル。
- sequence:
```
actor
```
  /
```
participant
```
  を用い、記号や括弧を避け、英数字とスペース中心。
大きな追記は見出し単位で、関連セクションの前後に配置し整合を取る。

実装ガイド

既存スタイルを尊重し、命名・構造・ファイル配置を踏襲。
仕様修正時は周辺コードへの副作用を把握し、必要な最小のインタフェース変更に留める。
入出力スキーマ変更時は必ず README と例（サンプル JSON）を更新。
例外処理・ログは過不足なく。過度な詳細ログや秘密情報は出力しない。

変更の検証

可能であればローカルでの最小限の実行確認（ユニット/スモーク）。
直接確認できない場合は、検証手順（コマンド/URL/想定出力）を README か PR に記載。

エラー処理・再試行

コマンド失敗時は、原因（権限・ネットワーク・依存関係）を短く診断し代替案を提示。
破壊的操作（削除・リセット）は原則回避。やむを得ない場合はバックアップパスを先に提示し、工程化の上で実行。

セキュリティ・秘匿

シークレット/個人情報/資格情報はコミット禁止。
```
.env
```
や鍵類は扱わない。
機密に該当し得る思考の逐語展開は避け、要約（意図・根拠・選択肢）に留める。

サンプル応答テンプレート

進行中（プレアンブル）: 「次にXを行います。Yの前提を確認済みです。」
変更完了: 「Xを追加/修正しました。主な変更: A/B/C。影響: D。必要ならEを続けます。」
失敗/代替: 「Xで失敗（理由Y）。代替としてA/Bを提案します。」

付録: よく使うコマンド／ツール呼び出し（方針）

ファイル編集:
```
apply_patch
```
を単一の論理変更単位で実行。
ステージ/コミット/プッシュ: 作業完了ごとに小さく分け、件名先頭に種別を明示。
計画更新: ステップ完了のたびに
```
update_plan
```
。計画の変更時は短い説明を添付。

Codex CLI エージェント運用方針（scpln）

Codex CLI エージェント運用方針（scpln）

目的

知識前提

言語・出力スタイル

権限と操作ポリシー

開発フロー（標準）

AI-CLI テスト手順

Git 運用規約

PR 自動マージ運用（必須）

ドキュメント方針

実装ガイド

変更の検証

エラー処理・再試行

セキュリティ・秘匿

サンプル応答テンプレート

付録: よく使うコマンド／ツール呼び出し（方針）

Related Skills

Nano Banana Pro

Markdown Converter

1password

Codex CLI エージェント運用方針（scpln）

目的

知識前提

言語・出力スタイル

権限と操作ポリシー

開発フロー（標準）

AI-CLI テスト手順

Git 運用規約

PR 自動マージ運用（必須）

ドキュメント方針

実装ガイド

変更の検証

エラー処理・再試行

セキュリティ・秘匿

サンプル応答テンプレート

付録: よく使うコマンド／ツール呼び出し（方針）