Promptware（プロンプトウェア）とは、自身の指示、メモリ（記憶）、ツール権限、実行履歴をファイルとして保持し、実行ごとに指示とメモリを自律的に改訂する自己完結型のAIエージェント単位です。Ivy Tendrilでは、プランのドラフト作成からPull Requestの発行に至るまで、ライフサイクルの各フェーズがこれらのPromptwareユニットによって実行されます。指示はリポジトリ内のバージョン管理されたファイルとして保存されるため、他のソースコードと同様にレビュー、差分確認（diff）、ロールバック、そしてチーム全体での共有が可能です。本記事では、ユニットの内部構造、実行ループ、7つの組み込みPromptware、そして注意すべき2つの失敗モード（リスク）について解説します。
Promptwareユニットの構成要素
Promptwareユニットは、4つのパーツで構成されるディレクトリです。各パーツには明確な単一の役割があります。
| パーツ | 内容 | 記述者 |
|---|---|---|
Program.md |
エージェントがそのフェーズで従う指示。実行後にエージェントが改訂し、人間がレビューする。 | エージェントおよび人間 |
Memory/ |
コードベースやチームの慣例に関する永続的な学習事項。実行ごとに追加記録される。 | エージェント |
Tools/ |
当該フェーズのスコープ限定された権限：エージェントが使用を許可されたコマンド、ファイル、連携機能。 | 人間 |
Logs/ |
実行履歴：エージェントが何を読み、何を実行し、何を変更し、どのような結論に至ったか。 | エージェント（追記のみ） |
Program.mdはコードではなく自然言語（散文）で記述されます。プラン実行ユニットのセクションの例は次のようになります：
## Pull Requestを発行する前に行うこと
- リポジトリのルートから `pnpm lint` と `pnpm test` を実行してください。どちらか一方でも失敗した場合はPRを開かないでください。
- 差分（diff）はプランで指定されたファイルのみに限定してください。別のファイルを変更する必要がある場合は、PRの説明欄にその理由を明記してください。
- コミットメッセージには `type(scope): summary` のフォーマットを使用してください。
メモリ（Memory）エントリには、コードを一目見ただけでは分からず、次回以降の実行で役立つ学習事項が記録されます：
### 2026-08-21, プラン #412
`src/billing/` 配下の請求モジュールにはテストがありません。リファクタリングを行う前にテストを追加してください。
`pnpm test` は最初にデータベースマイグレーションを実行します。クリーンなチェックアウト環境での実行には約4分かかります。
この2つのファイルは本質的に性質が異なります。「プログラム」は何をすべきか（手順）を規定します。「メモリ」はこのリポジトリについて何が事実であるか（状態）を記録します。これらを明確に分離することで、レビュー担当者は手順の変更を承認することなく新しい事実だけを受け入れることができ、その逆も可能になります。
実行ループ
すべてのPromptwareの実行は、共通の4つのステップに従います。
- プログラムの読み込み： エージェントは
Program.mdとTools/で定義された権限を読み込みます。付与された権限の範囲外にある操作にはアクセスできません。 - メモリの読み込み： エージェントは
Memory/を読み込み、過去の実行で得られた知見をあらかじめコンテキストに展開した上で作業を開始します。 - タスクの実行： 当該フェーズの作業を実施します（プラン作成、詳細化、Git worktree内での実行、Pull Requestの作成など）。呼び出されたすべてのツールとその出力は
Logs/に追記されます。 - 振り返りと書き戻し： 実際の実行結果とプログラムで想定されていた内容を比較・分析します。新しい事実は
Memory/に保存されます。指示に誤りや不足、重複があった場合、エージェントはProgram.mdを改訂します。
「行動し、結果を観察し、次の指示を修正する」というループは、推論エージェントに関するReAct論文で提唱されたパターンです。Promptwareの最大の特徴は、その修正結果がセッションの終了後も永続するファイルとして書き戻される点にあります。この第4ステップこそが、時間の経過とともに指示が劣化するのではなく自然に洗練されていく鍵となります。同時に、このステップは最も慎重な監視を必要とする部分でもあります（後述のリスクのセクションを参照）。
組み込みのPromptware
Ivy Tendrilには、GitHub IssueからPull Requestまでで解説しているライフサイクルの各フェーズに対応する7つのPromptwareが標準搭載されています。それぞれが独自のプログラム、メモリ、権限、ログを持っています。
- CreatePlan：アイデア、GitHub Issue、またはバグ報告をもとに、目標、スコープ、対象ファイル、検証手順を含むプランのドラフトを作成します。
- ExpandPlan：受け入れ基準の不足や未決定の設計方針など、実行に移すための情報が足りないドラフトに詳細情報を補完します。
- UpdatePlan：開発者からのインラインコメントやフィードバックを反映してドラフトを書き直します。
- SplitPlan：スコープが膨らみすぎたプランを、並列実行可能な複数の小さなプランに分割します。
- ExecutePlan：承認されたプランに従い、選択されたコーディングエージェント（Claude Code、Codex CLI、Copilot CLI、Gemini CLI、OpenCode、その他のCLIエージェント）を独立したgit worktree内で実行します。AnthropicのClaude Codeのベストプラクティスでも、本節の
Program.mdと同様に、指示ファイルをリポジトリで管理することの重要性が説かれています。 - CreatePr：差分が自動検証と人間のレビューに合格した後、GitHub上にPull Requestを作成します。
- CreateIssue：実行中に得られた推奨事項や発見された課題から、GitHub Issueを起票します。
各ユニットが独立しているため、CreatePlanのメモリ（例：「チームはプラン内で変更予定のテストファイルを明記することを求めている」など）がExecutePlanと混ざり合うことはなく、ExecutePlanに与えられたシェルコマンドの実行権限がCreatePlanに付与されることもありません。各ユニットの初期構成の詳細はPromptwareの公式ドキュメントに記載されています。
バージョン管理された指示と2つのリスク
なぜリポジトリ内のファイルがアドホックなプロンプトに勝るのか
チャットウィンドウにその場で打ち込まれたアドホックなプロンプトは、その場限りのものであり、セッションが終われば消失します。一方、リポジトリにコミットされた Program.md には、チャットプロンプトにはない4つの強力な利点があります。
- レビュー可能性（Review）： 指示への変更はPull Requestの差分（diff）として可視化されます。「変更が小さければテストをスキップする」といった不適切な指示が将来の実行に悪影響を及ぼす前に、シニアエンジニアがレビューで却下できます。
- 差分追跡（Diff）： 出力の品質に変化があった際、Promptwareディレクトリの
git logを見れば、どの指示がいつ変更されたのかが一目瞭然です。 - ロールバック（Rollback）： 誤った改訂が行われても、1回のコミットで即座に元の状態へ戻せます。
- チーム共有（Sharing）： チーム内のすべての開発者、そしてエージェントのすべての実行が同一の指示を共有します。月曜日の実行で獲得された慣例が、火曜日にはチーム全体に自然に適用されます。
これは、インフラ構築を手動設定からバージョン管理されたコード（IaC）へと移行させた論理や、The Twelve-Factor Appにおいて設定をコードから切り離す原則とまったく同じ理由に基づいています。エージェントのワークフロー構造化のパターンやPromptwareとの比較については、コーディングエージェントのためのオーケストレーションパターンでも詳しく解説しています。
リスク1：指示のドリフト（Instruction Drift）
自分のプログラムを編集できるエージェントは、時としてそれを改悪してしまう危険があります。たとえば、不安定な（flakyな）テストで失敗した実行によって「失敗したテストは最大3回再試行する」といったルールが追加され、次回以降に本質的なバグが見逃される原因になることがあります。これを抑制する仕組みが2つあります。第一に、プログラムはバージョン管理されたファイルであるため、変更はレビュー担当者が確認して破棄できるdiffとして提示されます。第二に、Logs/ に改訂の契機となった実行ログが記録されるため、変更を受け入れる前に推論の妥当性を人間が検証できます。
リスク2：メモリの肥大化（Memory Bloat）
ただ蓄積されるだけのメモリは、何の価値ももたらさずコストだけを増大させます。古い情報が半分を占める400件ものエントリを抱えたファイルは、実行のたびに無駄なトークンを浪費し、本当に有用な情報を見つけにくくします。これを防ぎ実用性を保つための実践が2つあります。上記サンプルのように各エントリに日付とスコープを明記し、陳腐化したエントリを特定しやすくすること。そしてレビュー時に剪定（プルーニング）することです。プランが特定の領域に触れる際、レビュアーは関連するメモリエントリを確認し、コードの現状に合致しなくなった記述を削除します。プランごとおよびジョブごとのコストとトークンの追跡により肥大化は可視化されます。メモリが過剰に膨らんだユニットは、プランの規模と釣り合わないトークン数の増加を示すためです。AIコーディングエージェントのスループット測定で、実行ごとのコストではなくマージされたPRごとのコストを指標とするのもこのためです。
はじめかた
Ivy Tendrilをインストールし、リポジトリを開いてプランを作成してください。初回実行時から7つの組み込みPromptwareがすべて利用可能です。
curl -sSf https://cdn.ivy.app/install-tendril.sh | sh
Windows環境では irm https://cdn.ivy.app/install-tendril.ps1 | iex を実行してください。最初のタスクを実行する前に Program.md を確認し、初期のメモリエントリやプログラムの改訂差分をコードレビューと同じ慎重さで確認してください。10個ほどのプランを処理すると、エージェントがつまずいた箇所の傾向がメモリに反映されるようになります。それは往々にして、人間のエンジニアもつまずきやすいポイントです。組み込みユニットの詳細はPromptwareドキュメントをご覧ください。
よくある質問
エージェントは無断でProgram.mdを変更しますか？
エージェントは実行完了後に自身のプログラムを改訂します。ただし Program.md はバージョン管理対象のファイルであるため、改訂内容は確認・承認・破棄が可能なGit差分として提示され、その原因となった実行ログも横に記録されています。
独自のPromptwareを自作することはできますか？
7つの組み込みユニットはライフサイクルの主要ステージを網羅しています。プログラム、メモリ、ツール権限はすべてプレーンテキストファイルであるため、チームの慣例に合わせて自由にカスタマイズ可能です。最新の拡張機能オプションについては公式ドキュメントをご確認ください。
メモリやログはどこに保存されますか？
Tendrilを実行しているローカルマシン内に保存されます。Ivyのサーバーにアップロードされることはありません。Tendrilが行うネットワーク通信は、設定されたLLMのAPIおよびGitHubとの通信のみです。
Ivy Tendrilで開発を加速する
開発者レベルの並列エージェントオーケストレーションを体験しませんか？
- ソースコードを確認: GitHubのIvy Tendrilリポジトリ（オープンソース）
- 技術ドキュメント: tendril.ivy.appの統合ガイドを参照
- アーキテクチャ相談: renco@ivy.appまでお気軽にお問い合わせください（30分の技術相談）