Prompt Request — Pull Request の次の形：コードを書く時代から「意図を書く時代」へ

@The_AGI_WAY（ハヤシシュンスケ）氏のポストが話題です。

コードを書く時代から、意図を書く時代へ。GitHub Issue にこう書く。「[auto] ユーザー認証のエラーハンドリングを追加しろ」

引用元は @Shuns_AI 氏が X で公開した長文記事「Prompt Request — Pull Request の次の形」です。AI エージェントが GitHub Issue を読み取り、ブランチ作成から実装・テスト・PR 作成・マージまでを自律的に完了するワークフローを提案しています。92 タスクで 95% の成功率を達成したという実績とともに、「良い Issue を書く能力」こそが開発者の最重要スキルになるという主張が注目を集めました。

「Prompt Request」とは何か

「Prompt Request」は、従来の Pull Request（PR）に代わる新しい開発パラダイムを表す概念です。

PR がコードの差分を中心とした「成果物の提出」であるのに対し、Prompt Request は「意図の伝達」が起点になります。開発者が書くのはコードではなく、何をしたいかという自然言語の指示です。

ワークフローの全体像

記事で提案されているワークフローは次のとおりです。

1. 開発者が GitHub Issue に [auto] タグ付きで指示を記述
2. AI エージェントが Issue を検知・パース
3. リポジトリのコードベースを解析
4. 新規ブランチを作成
5. コードを実装
6. テストを作成・実行
7. Pull Request を作成
8. AI がピアレビューを実施
9. 条件を満たせば自動マージ

全工程が 5〜15 分で完了するとされています。人間の介入がゼロで完結するケースもあり、開発者は Issue を書いた後、完了通知を待つだけです。

実績：92 タスクで 95% 成功

記事では、このワークフローの実績として以下の数字が報告されています。

• 検証タスク数: 92
• 成功率: 95%
• 自動マージされた PR: 12 件
• 自動クローズされた Issue: 8 件

95% という数字は、実用に耐えるレベルに達していることを示しています。残り 5% の失敗ケースの分析も重要ですが、ルーチン的な開発タスクの大部分を AI に委譲できる可能性を示唆しています。

SWML 理論と Ω 関数

記事の特徴的な点は、単なるツール紹介に留まらず、理論的なフレームワークを提示していることです。

SWML（Shunsuke’s World Model Logic） は、LLM の振る舞いを物理学の場の理論にインスパイアされたモデルで記述する試みです。中核となる Ω 関数 は次のように定義されます。

Ω: I × W → R

この定式化の意義は、Issue 本文の精度（I の質）がそのまま成果物の品質を支配するという洞察を数学的に表現している点です。入力の情報エントロピーが測定可能になるため、「良い Issue」と「悪い Issue」の違いを定量的に評価できる可能性があります。

Issue の質が最重要スキルになる

この理論から導かれる実践的な結論は明確です。

「良い Issue を書く能力」が最重要スキルになる

コードを書く能力ではなく、意図を正確に伝える能力が開発者の価値を決める時代が近づいているという主張です。具体的には、以下の要素が「良い Issue」を構成します。

• 明確なゴール: 何を達成したいかが一意に定まる
• コンテキスト: 関連するコード、設計方針、制約条件の提示
• 受け入れ基準: 完了条件が具体的に定義されている
• スコープの限定: 1 つの Issue が 1 つの変更に対応する

これは従来のプロンプトエンジニアリングの知見とも重なりますが、GitHub Issue というフォーマットに特化している点が新しいです。

GitHub Copilot Coding Agent との比較

この「Prompt Request」の概念は、GitHub が公式にリリースした Copilot Coding Agent と方向性を同じくしています。

Copilot Coding Agent は Issue をアサインすると 👀 リアクションを付けてバックグラウンドで作業を開始し、ドラフト PR としてコミットを積み上げていきます。スクリーンショットやモックアップの画像解析にも対応しており、視覚的な指示も受け付けます。

また、CodeAgent のように Claude Code と GitHub Actions を組み合わせた自作ソリューションも登場しています。/claude コマンドで Issue やPR コメントから AI エージェントをトリガーし、5 分以内にバグ修正の PR が作成される事例が報告されています。

プロンプトからコンテキスト設計へ

「Prompt Request」の議論は、より大きなトレンドの一部です。2026 年に入り、プロンプトエンジニアリングからコンテキスト設計（Context Engineering）への移行が加速しています。

LinkedIn のデータによると、「Prompt Engineer」の求人数は 2024〜2025 年にかけて 40% 減少しました。AI が「単発の質問応答」から「継続的なタスク実行」へと進化したことで、必要なスキルが変わったのです。

AI 活用の成功を握る工数の 7 割は、プロンプトの微調整ではなく「前提条件（コンテキスト）」の設計にあるとされています。これはまさに Prompt Request の「Issue 本文の精度が成果物の品質を支配する」という主張と一致します。

過去の Gist 記事との関連性

「プロンプトからコンテキスト設計へ」という流れは、これまでの Gist ブログ記事で繰り返し取り上げてきたテーマです。今回の Prompt Request の議論は、これらの記事と一本の線で繋がっています。

コンテキスト重視の 4 記事マップ

進化の 5 段階モデル

テキスト勾配の記事で提示した 4 段階モデルに、Prompt Request を加えると 5 段階に拡張できます。

Level 1: プロンプトエンジニアリング
  → 質問の仕方を工夫する（手動・属人的）

Level 2: コンテキストエンジニアリング
  → 何を知った状態で考えさせるかを設計する（手動・体系的）

Level 3: コンテキストの制御基盤（Harness）
  → コンテキストをシステムとして管理する（Reduce / Offload / Isolate）

Level 4: コンテキストの自動最適化
  → コンテキスト自体をテキスト勾配で自動的に改善する

Level 5: Prompt Request（意図駆動の自律開発）  ← NEW
  → Issue という「構造化されたコンテキスト」を起点に
     AI が自律的に開発サイクル全体を完結させる

Prompt Request は Level 5 に位置します。Issue は単なるプロンプトではなく、ゴール・背景・受け入れ基準・制約を含む構造化されたコンテキストです。Harness がコンテキストを管理し（Level 3）、テキスト勾配が Issue テンプレートを改善し（Level 4）、最終的に AI が Issue を読んで自律的に開発を完結させる（Level 5）——という積み上げの関係にあります。

Ω 関数と Harness の 3 原則の対応

SWML の Ω 関数（I × W → R）を、Harness 記事の 3 原則で読み解くと、各原則が Ω 関数のどの変数に作用するかが明確になります。

つまり、「良い Issue を書く」とは Ω 関数の I の質を高めることであり、「良い開発環境を整える」とは W の質を高めることです。Harness の 3 原則は W を効率的に管理するための具体的な手法として機能します。

一貫したメッセージ

これらの記事に共通する主張は一つです。

AI の品質を決めるのは、モデルの性能でも、プロンプトの巧みさでもなく、AI に渡すコンテキストの質である。

MCP 記事ではスキーマがコンテキストを圧迫する問題を指摘し、Harness 記事では Reduce / Offload / Isolate でコンテキストを守る設計を提示し、テキスト勾配記事ではコンテキスト自体を自動改善する手法を紹介しました。そして今回の Prompt Request は、この文脈の延長線上にある「コンテキスト設計の究極形」——Issue という構造化されたコンテキストだけで開発サイクル全体を駆動する世界観を示しています。

開発者への実践的な示唆

Prompt Request のコンセプトを今日から取り入れるための実践的なアプローチを整理します。

1. Issue の書き方を改善する

AI エージェントを使うかどうかに関わらず、Issue の質を上げることは開発効率に直結します。

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17

## 良い Issue の例

### タイトル
[auto] ユーザー認証のエラーハンドリングを追加

### 背景
現在、認証失敗時にジェネリックな 500 エラーが返される。
ユーザーに適切なエラーメッセージを返す必要がある。

### 受け入れ基準
- パスワード誤り → 401 + "パスワードが正しくありません"
- アカウントロック → 423 + "アカウントがロックされています"
- トークン期限切れ → 401 + "セッションの有効期限が切れました"

### 制約
- 既存のテストが壊れないこと
- エラーメッセージは i18n 対応すること

2. 既存ツールを活用する

GitHub Copilot Coding Agent が利用可能であれば、まず低リスクなタスクから試してみることが推奨されます。

• 適したタスク: テストの追加、リファクタリング、ドキュメント更新、軽微なバグ修正
• 避けるべきタスク: アーキテクチャの大幅変更、セキュリティクリティカルな実装

3. レビュー体制を整える

AI が生成したコードの品質保証は人間の責任です。自動マージを導入する場合でも、以下のガードレールが必要です。

• CI/CD パイプラインでのテスト自動実行
• コードカバレッジの閾値設定
• セキュリティスキャンの必須化
• 変更サイズの上限設定

注意点と限界

Prompt Request のビジョンには魅力がありますが、現時点での限界も認識しておく必要があります。

• 複雑なタスクへの対応: 低〜中程度の複雑さのタスクには有効ですが、アーキテクチャ設計や複数サービスにまたがる変更には不向きです
• セキュリティリスク: AI エージェントがコードベースにアクセスするため、機密情報の取り扱いに注意が必要です
• 品質の担保: 95% の成功率は高いですが、残り 5% の失敗がクリティカルな問題を引き起こす可能性があります
• SWML 理論の検証: Ω 関数による定式化は興味深いですが、学術的な検証はこれからです
• チーム開発への適用: 個人プロジェクトでの実績が中心であり、大規模チームでの運用実績は限定的です

まとめ

• 「Prompt Request」はコードではなく意図を書く新しい開発パラダイムであり、GitHub Issue が起点となる
• 92 タスクで 95% の成功率を達成しており、ルーチン的な開発タスクの自動化が現実的になっている
• **SWML 理論の Ω 関数（I × W → R）**は、Issue の精度が成果物の品質を支配するという洞察を数学的に表現している
• 「良い Issue を書く能力」が最重要スキルになるという主張は、プロンプトからコンテキスト設計への移行トレンドと一致する
• GitHub Copilot Coding Agent など公式ツールも同じ方向に進化しており、Issue 駆動の自律型開発は業界全体のトレンドとなっている
• 現時点では低〜中程度の複雑さのタスクが対象であり、複雑なアーキテクチャ変更やセキュリティクリティカルな実装には人間の関与が不可欠

参考

• @The_AGI_WAY 氏のポスト
• @Shuns_AI 氏の記事「Prompt Request — Pull Request の次の形」
• GitHub Copilot Coding Agent 公式ドキュメント
• GitHub Copilot：新しいコーディングエージェント（GitHub ブログ日本語版）
• GitHub 上で依頼して PR 作成する自律型 AI エージェントを作った（blog.potproject.net）
• Github Issue をアサインしたらコード修正 & PR 出す AI Agent をつくる（DevelopersIO）
• プロンプトの時代は終わった──2026 年、AI との対話は「コンテキスト設計」へ
• ハヤシ シュンスケ「The AGI Way Co-pilot」プレスリリース