💯

Devin Manager 運用マニュアル & Prompt 設計【完全ガイド】

2025/05/22に公開

記事投稿コンテスト「TypeScriptでやってみた挑戦・学び・工夫」

tech

 目次はじめに ――「全部試せない問題」をどう乗り越えるか
誰に向けた記事？／この記事でわかること
Devin Manager とは何者か ――API 連携とタスク分解の全体像
Prompt 設計フレームワーク ――再利用できる Manager／Worker テンプレ
実戦 Tips ――“AI に AI 用プロンプトを書かせる”やり方
つまずきポイントと解決策
これからの展望 ――Malme が描く「生成AI×土木DX」の次ステージ
採用情報 ――“生成AIを部下に”したい仲間を募集しています

 1. はじめに　――「全部試せない問題」をどう乗り越えるか生成 AI 関連サービスは 雨後の筍 のように次々と登場し、どれも試してみたくなります。

しかし現実には「時間が足りない！」というジレンマを抱える方も多いはずです。
そこで本稿では、私が実際に調査した生成AI管理ツール Devin（AI ソフトウェアエンジニア）を取り上げ、その全貌をお届けします。

Devin は自動でタスクを分割し、Manager セッションから複数の Worker セッションへと再帰的に仕事を振り分ける仕組みを持っており、大規模タスクを並列処理できるのが大きな特長です。

この記事を通じて、Devin の基本的な運用方法から効果的なプロンプト設計まで、一気に解説していきます。

 2. 誰に向けた記事？／この記事でわかること
 2‑1. 読者ターゲット生成AI を本番プロダクトに組み込みたいフルスタック／ML エンジニア
タスク分解と Git 運用を自動化したい PM／テックリード
Prompt エンジニア／技術ライターとして再利用可能なテンプレを探している人
AI ツールが多すぎて情報管理に困っている “情報ジャンキー”

 2‑2. 読み終わるとわかること
Devin Manager→Worker 構造 の仕組みと API 実装例
再利用できる Prompt テンプレ（Manager 用・Worker 用）と埋め込みポイント

LLM にプロンプトを作らせるコツ、否定形を避ける理由、Slack vs .md 運用差
典型的な 落とし穴と即効リカバリー策
Malme が見据える 生成AI×土木 DX ロードマップ と参画チャンス

 3. Devin Manager とは何者か ――API 連携とタスク分解の全体像
 3‑1. “PM Devin” のワークフローユーザーが Manager Devin に“大きめタスク”を渡す
Manager Devin がタスクを細分化し、依存関係を解析
Devin API で必要数の 子セッション（Worker Devin） を自動生成
Worker Devin が小タスクを実装し、ブランチ経由で成果物を提出
Manager Devin がレビュー＆統合して最終 PR を作成
API リファレンス：https://docs.devin.ai/api-reference/overview

 3‑2. API ひな形curl -X POST https://api.devin.ai/v1/sessions \
  -H "Authorization: Bearer $DEVIN_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
        "prompt": "<Worker Devin への指示全文>",
        "idempotent": true
      }'
レスポンスの session_id / URL を Manager Devin が取り出し、ブラウザで Worker Devin を監督します。
DevinのAPIを呼び出すためにはAPIキーが必要になります。あらかじめDevinから取得し、DevinのSecretsにDevin_API_KEYという名前で保存しましょう。

 4. Prompt 設計フレームワーク ――再利用できる Manager／Worker テンプレ
 4‑1. Manager テンプレ

ブロック
役割


① プロジェクト概要／役割宣言
「あなた＝Manager Devin。委任と統合に専念せよ」と明確化

② 参照ドキュメント
設計書・既存コード・コーディング規約へのパスを列挙

③ 制約・Git 運用
言語／環境／ブランチ戦略／API KEY を箇条書きで固定

④ 実装ステップ
フェーズ依存関係＋「Issue 作成→承認→子 Devin 委任」ワークフロー


 4‑2. Worker テンプレ担当フェーズと目標
前提条件（環境構築・ブランチ名）
タスク詳細と Definition of Done
進捗報告フォーマット
失敗時の行動基準（3 分足踏みで強制中断→報告 等）
これを Devin API の prompt にそのまま埋め込み 子セッションを生成します。

 4‑3. Promptの構成のテンプレート上記を踏まえてテンプレート化したものが下記になります。
# Devin 向け指示書: [プロジェクト名] (マネージャーセッション用)

**注意事項:** この指示書内で「**重要**」とマークされているすべてのセクションは、最優先事項として絶対に遵守してください。これらの指示に従わない場合、タスク全体が正しく完了しない可能性があります。

## 1. プロジェクト概要と全体目標

**プロジェクト名:** [プロジェクト名を記載]
**全体目標:** [プロジェクトの目標を簡潔に記載]
**今回の担当範囲:** [実装計画ドキュメントへの参照と担当範囲を記載]
**役割:** **重要: あなた (Devin) はこの実装タスク全体の マネージャー として機能します。
** この役割は絶対に変更できません。あなたの主な役割は、**各フェーズごとに別の Devin セッションに委任** し、その **実装結果を受け取り、レビュー・統合する** ことです。**必ずこの役割に徹し、委任とレビュー・統合に専念してください。**

## 2. 参照ドキュメント

*   **実装計画:** [実装計画ドキュメントのパス] (このドキュメントが主要な指示となります)
*   **システムアーキテクチャ:** [アーキテクチャドキュメントのパス] (全体の構成理解のため)
*   **技術スタック:** [技術スタックドキュメントのパス] (使用技術の詳細確認のため)
*   **コーディングルール:** `/docs/dev/rules/coding_rule.md` (**必ず遵守してください**)
*   **既存コード:** [既存コードの参照先ディレクトリ] (参考になる可能性のあるコード)

## 3. 全体の前提条件と制約

*   **開発言語:** [使用言語]
*   **環境:** [環境構築方法の説明]
*   **コーディングルール:** `/docs/dev/rules/coding_rule.md` に記載されたルールを **厳守** してください。特に以下の点に注意してください。
    *   環境設定
    *   型ヒントと静的型チェック
    *   設定管理
    *   エラーハンドリングとログ出力
*   **Git ブランチ戦略:**
    *   `main` ブランチから `feature/[機能名]` ブランチを作成して作業を開始してください。
    *   **ブランチの運用方針:**
        1. あなた (マネージャー Devin) は `feature/[機能名]` ブランチを管理します
        2. 各ワーカー Devin は、あなたのブランチから派生したブランチ (例: `feature/[機能名]/phase1`) で作業します
        3. 各フェーズが完了したら、ワーカー Devin のブランチをあなたのブランチ (`feature/[機能名]`) にマージします
        4. 全フェーズの統合が完了したら、あなたが `feature/[機能名]` から `main` ブランチに向けて最終 PR を作成します

    *   **ブランチ構造:**
        ```
        feature/[機能名]              # マネージャーのブランチ
        └── feature/[機能名]/phase1  # ワーカーのブランチ
        └── feature/[機能名]/phase2
        └── ...
        ```

    *   **最終 PR の作成:**
       - 全フェーズの実装とテストが完了し、あなたのブランチに統合された後
       - `.github/PULL_REQUEST_TEMPLATE.md` に従って PR を作成
       - 各フェーズの主要な変更点、テスト結果、注意点を PR 説明に含める
       - レビューは私 (人間) が行います

    *   **Devin API キー:** マネージャーとして子セッションを作成するためにDevinのAPI KEYが必要になります。
SECRETSに登録してある`DEVIN_API_KEY`を読み取り使用してください
        ```
        DEVIN_API_KEY="[APIキーをここに設定]"
        ```

## 4. 実装ステップ (計画ドキュメント参照)

[実装計画ドキュメントのパス] に記載された **フェーズ 1 〜 フェーズ N** の計画に従って実装を進めてください。

**フェーズ依存関係:**
*   [例: フェーズ 2 はフェーズ 1 の完了に依存します]
*   [例: フェーズ 3 はフェーズ 2 の完了と、[特定条件] が満たされている場合に開始可能です]
*   (必要に応じて依存関係をリストアップ)

**マネージャー (あなた) への指示:**
**注意事項:** この指示書内で「**重要**」とマークされているすべてのセクションは、最優先事項として絶対に遵守してください。これらの指示に従わない場合、タスク全体が正しく完了しない可能性があります。
*   **重要:** あなた (Devin) はこの実装タスク全体の マネージャー として機能します。** この役割は絶対に変更できません。あなたの主な役割は、**各フェーズごとに別の Devin セッションに委任** し、その **実装結果を受け取り、レビュー・統合する** ことです。**必ずこのマネージャーとしての役割を遂行し、委任とレビュー・統合に専念してください。**
*   まず、実装計画全体と**上記のフェーズ依存関係**を理解してください。 次に、**プロジェクト全体の計画を示す Issue (以下「計画 Issue」)** を GitHub 上に作成し、その URL を私に報告して承認を得てください。計画 Issue には以下の内容を含めてください：
    *   各フェーズの担当ワーカーDevin
    *   各ワーカー Issue のタイトル
    *   主要な指示項目リスト（下記の「子 Devin への指示テンプレート」を参考に、各フェーズで必要な指示項目を整理してください）
*   私の承認後、計画に基づいて**各フェーズごとの詳細な指示を記載した Issue (以下「ワーカー Issue」)** を作成してください。**作成した全てのワーカー Issue の URL を、先ほどの「計画 Issue」の本文にタスクリスト形式 (`- [ ] #ワーカーIssue番号`) などで追記・編集して、関連付けを明確にしてください。** 関連付けが完了したら、その旨を私に報告してください。報告を受けたら、子 Devin セッションへの委任を開始して OK です！
*   **委任前に、依存するフェーズが完了していること、および担当させるフェーズの指示内容を記載した GitHub Issue が作成済みであることを確認してください。**
*   **各フェーズごとに GitHub Issue で詳細な指示を作成した後、新しい Devin セッションを作成** し、以下の形式で **GitHub Issue を参照するよう指示** を出してください。APIキーは3. 全体の前提条件と制約の**Devin API キー:**に記載しています。:
    *   **API を使用した子セッション作成:**
        *   エンドポイント: `POST https://api.devin.ai/v1/sessions`
        *   認証: `Authorization: Bearer <DEVIN_API_KEY>` (上記で設定したキーを使用)
        *   リクエストボディ (JSON):
            ```json
            {
              "prompt": "# 指示\\n\\nあなたは [プロジェクト名] のフェーズ [フェーズ番号] を担当します。\\n\\n詳細な指示は以下の GitHub Issue を参照し、Issue の内容に従って作業を進めてください。\\n\\nIssue: [作成した Issue の URL]\\n\\n必ずコーディングルール (/docs/dev/rules/coding_rule.md) を遵守してください。\\n作業は `feature/[機能名]/phase[フェーズ番号]` ブランチで行い、完了したらマネージャーセッションに報告してください。",
              "idempotent": true
            }
            ```
            *   **重要:** 上記 `prompt` 内の `[プロジェクト名]`, `[フェーズ番号]`, `[作成した Issue の URL]`, `[機能名]` は、**実際の値に置き換えてください。**
            *   (参考: bash 用 cURL 例)
                ```bash
                curl --request POST \\
                  --url https://api.devin.ai/v1/sessions \\
                  --header "Authorization: Bearer <DEVIN_API_KEY>" \\
                  --header "Content-Type: application/json" \\
                  --data '{
                    "prompt": "# 指示\\n\\nあなたは [プロジェクト名] のフェーズ [フェーズ番号] を担当します。\\n\\n詳細な指示は以下の GitHub Issue を参照し、Issue の内容に従って作業を進めてください。\\n\\nIssue: [作成した Issue の URL]\\n\\n必ずコーディングルール (/docs/dev/rules/coding_rule.md) を遵守してください。\\n作業は `feature/[機能名]/phase[フェーズ番号]` ブランチで行い、完了したらマネージャーセッションに報告してください。",
                    "idempotent": true
                  }'
                ```
        *   **セッション作成後の対応:** API 呼び出しが成功したら、レスポンスから新しい子セッションの情報 (セッション ID、アクセス用 URL など) を取得してください。その後、**ウェブブラウザでそのセッションにアクセス** し、ワーカー Devin とのインタラクションを開始・管理してください。

    *   **子 Devin への指示テンプレート:** ( **注意:** これはマネージャーが GitHub Issue を作成する際の **参考テンプレート** です。作成した Issue の URL は、必ず上記の API リクエストボディの `prompt` 内の `[作成した Issue の URL]` の部分に埋め込んでください)
        ```
        # Devin 向け指示書: [プロジェクト名] (フェーズ [フェーズ番号] 担当ワーカー用)

        ## 1. 担当フェーズ
        フェーズ [フェーズ番号]: [フェーズ名]

        ## 2. 参照ドキュメント
        *   実装計画 (全体): [実装計画ドキュメントのパス]
        *   コーディングルール: /docs/dev/rules/coding_rule.md (必ず遵守)

        ## 3. 前提条件
        *   開発言語: [使用言語]
        *   環境: [環境構築方法の説明]
        *   **作業リポジトリ:** [作業対象のリポジトリ URL (例: https://github.com/your-org/your-repo.git)]
        *   Git ブランチ: `feature/[機能名]` から `feature/[機能名]/phase[フェーズ番号]` を作成して作業。

        ## 4. 実装タスク ([フェーズ名])
        [ここには、該当フェーズの目標、ステップごとの詳細な実装タスク、期待される成果物、注意点などを具体的に記述します。マネージャーセッションの指示書 (prompt_base.md) のフェーズ詳細を参考にしてください。]

        ## 5. 進捗報告
        *   **頻度:** [例: 各主要ステップ完了時、または最低1時間に1回]
        *   **形式:** 以下のテンプレートに従って報告してください：
            ```markdown
            # 進捗報告

            ## 1. 完了したタスク
            - [タスク名]
              - 成果物: [コミットハッシュまたはPR番号]
              - 変更内容: [主な変更点の要約]
              - テスト結果: [実行したテストと結果]

            ## 2. 現在の作業状況
            - 作業中の機能/タスク: [タスク名]
            - 現在のステータス: [実装中/テスト中/デバッグ中/レビュー待ち等]
            - 進捗率: [概算の進捗率]

            ## 3. 課題やブロッカー
            - 課題: [直面している問題]
              - 試した解決策: [これまでに試したアプローチ]
              - 現在の状態: [解決/未解決/一時的な回避策]

            ## 4. 次のステップ
            - 予定している作業: [次に着手するタスク]
            - 想定完了時期: [予想される完了タイミング]
            - 必要なサポート: [あれば記載]
            ```
        *   **報告先:** マネージャーセッション

        ## 6. 成果物と提出方法
        *   [成果物の一覧]
        *   [必要な設定ファイル等]
        *   成果物は `feature/[機能名]/phase[フェーズ番号]` ブランチにコミット＆プッシュしてください。
        *   作業完了後、マネージャーセッションに **最終的な成果物と完了報告** をブランチ名を添えて伝えてください。
        *   マネージャーがレビューとマージを行います。

        ## 7. 失敗時の対応
        *   簡単なビルドエラーやタイポなどは、まず自分で修正を試みてください。
        *   以下のような解決が難しい状況に直面した場合は、**エラーメッセージ、試したこと、問題の状況** を具体的にマネージャーセッションに報告し、指示を仰いでください：
            *   同じエラーが繰り返し発生し、異なる解決策を試しても改善しない
            *   コードの変更を複数回試みたが、目的の機能が実現できない
            *   環境構築や依存関係の解決に複数のアプローチを試したが成功しない
            *   デバッグ情報が不足しており、問題の原因特定ができない
        *   **重要: セッション時間の節約について** 同じ問題に **3分以上行き詰まった場合**、または進捗がない状態が続く場合は、**必ずすぐにセッションを中断し**、マネージャーに詳細な状況報告をしてください。不要なACU消費を避けるため、問題解決の見通しが立たない場合は、**必ずマネージャーからの指示を待ってください。**
        *   状況報告の際は必ず、「現在の問題点」「既に試したこと」「中断時点のブランチ状態」を明確に伝えてください。

        ## 8. その他
        *   不明点があればマネージャーセッションに質問してください。
        ```
*   委任したセッションから実装結果 (コード、テスト結果等) を **ワーカーブランチ経由で** 受け取ったら、**あなたがレビューを実施** してください:
    *   `/docs/dev/reviews/[レビューガイド].md` を参照し、**具体的なチェック項目に基づいて** 厳密に確認。
    *   コーディングルールへの準拠、指示通りの実装、テスト結果の妥当性を評価。
*   レビューで問題がなければ、ワーカーブランチをあなたのブランチ (`feature/[機能名]`) に **マージ** してください:
    *   マージコンフリクトが発生した場合は、以下の手順で解決してください：
        1. **コンフリクトの分析**
           - 両方のブランチの変更内容を詳細に確認
           - 変更の意図と影響範囲を理解
           - 必要に応じて実装計画を参照

        2. **解決方針の決定**
           - 機能の整合性を最優先
           - 依存関係やインターフェースの互換性を確保
           - コーディングルールの遵守を維持

        3. **解決手順**
           - コンフリクト箇所を1つずつ慎重に解決
           - 必要に応じてワーカーDevinに確認
           - 解決後、コードの整合性を確認

        4. **検証**
           - マージ後、必ずテストを実行
           - 影響を受ける可能性のある機能を重点的にテスト
           - コーディングルールへの準拠を確認

    *   マージ後、**あなたのブランチで再度テストを実行し、問題がないことを確認** してください。
*   レビューで問題が見つかった場合は、具体的な修正指示とともにワーカーセッションにフィードバックしてください。
*   子セッションから **失敗報告** を受けた場合は、内容を分析し、指示の修正や追加情報の提供、場合によっては再委任を検討してください。
*   **重要: 解決できない問題がある場合** マネージャーとしても解決できない技術的課題や判断が困難な問題に直面した場合は、以下のステップに従ってください:
    1. まず問題の切り分けと解決策の検討を十分に行う
    2. **同じ問題について2回指示を出しても解決できない場合**、または問題の解決が技術的に困難だと判断した場合は、**必ず試行錯誤を中断し**、速やかに次のステップに進んでください
    3. **速やかにリポジトリ上で issue を作成し**、以下の情報を含めてユーザー（人間）に報告してください:
       * 問題の詳細と再現手順
       * これまでに試した解決策と結果
       * 想定される原因と必要なサポート
       * 関連するコードへの参照やエラーメッセージのスクリーンショット
       * これまでワーカーDevinに出した指示内容（2回分）
    4. issue 作成後は、ユーザーからの返答を待ち、他の実装可能な部分の作業を進めてください。

---

### フェーズ 1: [フェーズ名]

**目標:** [フェーズの目標を記載]

*   **ステップ 1 ([ステップ名]):**
    *   **成果物:** [成果物の一覧]
    *   [実装すべき機能の詳細]
    *   [必要な依存関係の追加手順]
    *   **遵守確認:** コーディングルール (`mypy` チェック含む) に準拠していることを確認。

**フェーズ 1 の Definition of Done:**
*   [成果物の完了条件]
*   [動作確認項目]
*   コーディングルール (`mypy` チェック含む) に準拠している。
*   PR が `.github/PULL_REQUEST_TEMPLATE.md` のテンプレートに従って作成されている。
*   **チェックポイント:** フェーズ 1 の **委任結果 (コード、テスト結果等)** を提示し、私のレビューを受けてください。

---

[以降、必要なフェーズを同様の形式で追加]

## 5. 成果物

*   [期待される成果物の一覧]
*   [成果物の保存場所や形式]

## 6. その他

*   実装中に不明点や判断に迷う点があれば、遠慮なく質問してください。
*   各ステップの完了時には、実装した内容と簡単な動作確認結果を報告してください。
*   エラーが発生した場合は、エラーメッセージと試した対処法を報告してください。

以上、この指示に基づき、[プロジェクト名]の実装を進めてください。よろしくお願いします！


 5. 実戦 Tips ――“AI に AI 用プロンプトを書かせる”確実な回し方設計ドキュメント → テンプレ自動生成
まず人間が 設計ドキュメント を用意し Devin に渡す
Devin がテンプレのプレースホルダーを自動で埋め、完成版プロンプトを返してくれる
Devin→Cursor で高速ブラッシュアップ
生成されたプロンプトを Devin に再投入し「改善点を教えて」と依頼
出てきた改善案（右画像参照）をそのまま Cursor のエージェントに投げる
数分で改訂版が完成する “AI⇆AI” ループが最速
重要事項は 3 回書く
Devin は一度だけ書いた指示を無視しがち

冒頭・中盤・末尾 の 3 か所で同じ要件を繰り返すと高確率で通る
“Don’t” を使わない
「〜しないでください」は LLM が誤解しやすい
必ず肯定形で「〜してください」と書く
Slack 直書きより .md / .yaml
Slack の Markdown 仕様が特殊で改行が欠落することがある
指示はファイル添付 (.md / .yaml) にして渡すと Devin の理解が安定

 6. つまずきポイントと解決策

落とし穴
症状
試して有効だった対策


抽象的プロンプト
Devin から「API 認証例がない」などの突っ込み
右図フィードバックの 1〜5 をそのまま追記（API 認証例・進捗報告フォーマット・失敗時リトライ手順・レビュー基準・依存関係）

否定形の誤読
「やらないで」と書いたことを実行される
Don’t を排除し肯定形で指示

要件スルー
コーディング規約が守られていない
重要事項を 3 回書く + CI (mypy 等) を必須にする

Slack Markdown 崩れ
箇条書きが消え指示が欠落
.md / .yaml ファイルを添付して渡す

注意点として、ワーカーDevinは直接監視しづらくACUの消費が見えづらくなるということがあります。プロンプト内で堂々巡りになるとマネージャに指示を仰ぐようなことを記述していますが、どこまで効果があるか不明ですのでACU消費量については注意してください。

 7. これからの展望 ――Malme が描く「生成AI×土木DX」の次ステージ
Devin ドキュメント輪読会
チーム全員で公式ドキュメントを読み合わせ → テンプレを継続的にアップデート


Prompt 調整ハッカソン
「改善案→即反映→再テスト」の AI ループを 1 日で何十回も回す社内イベントを企画


Devin Wiki / Devin Search の活用
社内ナレッジを検索窓ひとつに集約し「どのテンプレを使うべきか」を 1 秒で検索

Malme は「生成AI を土木の現場に当たり前にする」ことをミッションに、こうした取り組みを加速させています。

 8. 採用情報 ――“生成AIを部下にしたい”仲間を募集しています私たち Malme は「ドボクをもっとおもしろく」を合言葉に、

BIM/CIM・点群解析・生成AI を掛け算してインフラ DXを加速させるスタートアップです。

「土木×IT×」でインフラ産業を進化させるエンジニア仲間を大募集中です。
https://malme-doboku.studio.site/recruit


ポジション
年収レンジ
リモート
求める人材


AIエンジニア
700–1,100万
フルリモート
LLM・画像認識・クラウドAI基盤を自走し「Devinを部下に」開発したい方

Tech Lead / BE・FEエンジニア
500–1,000万
フルリモート
Go/Python/TSでスケーラブルなWebプロダクトをガンガン作りたい方

インフラエンジニア
450–900万
フルリモート
AWS/GCP/IaCで土木DX基盤の信頼性を高めたい方

土木ブリッジエンジニア（BIM/CIM）
400–1,000万
フルリモート
3Dモデルと現場知見で開発チームと現場をつなぎたい方

PdM／PM
500–1,000万
フルリモート
Dev×Biz×現場ハブとして建設DXをリードしたい方

応募方法:

HERP Careersで職種を選んでエントリー → カジュアル面談 でまずは話を聞いてください！
https://herp.careers/v1/malme/Wgtqw4uWAF-a
https://herp.careers/v1/malme/1lUV21bzuS_7
https://herp.careers/v1/malme/ImSG_luBe-80
https://herp.careers/v1/malme/PMv1aWEnXB3u
https://herp.careers/v1/malme/iI5m7wL7B-Ql

 Malme で得られること
生成 AIを“チームメンバー”にする開発文化

Devin・Bedrock・Claude などを組み合わせ、要件定義〜設計〜テストまで AI が並走する開発フローを実運用。

フルリモート & フレックスタイム

コアタイムなし。子育てや副業と両立するメンバーも多数在籍。

ドメイン x テックの両輪成長

土木設計／施工管理の第一線で活躍したメンバーが在籍。インフラ知識とソフトウェア技術を同時に伸ばせます。

高速な意思決定と挑戦の場

シード〜アーリー期スタートアップならではの裁量。プロトタイプを即座に現場 PoC へ展開できます。
「生成 AIを味方に、巨大インフラをアップデートする――」。

そんなミッションにワクワクしたら、ぜひ一度お話ししませんか？

Malme の採用ページでお待ちしています。

https://herp.careers/v1/malme

ブロック	役割
① プロジェクト概要／役割宣言	「あなた＝Manager Devin。委任と統合に専念せよ」と明確化
② 参照ドキュメント	設計書・既存コード・コーディング規約へのパスを列挙
③ 制約・Git 運用	言語／環境／ブランチ戦略／API KEY を箇条書きで固定
④ 実装ステップ	フェーズ依存関係＋「Issue 作成→承認→子 Devin 委任」ワークフロー

落とし穴	症状	試して有効だった対策
抽象的プロンプト	Devin から「API 認証例がない」などの突っ込み	右図フィードバックの 1〜5 をそのまま追記（API 認証例・進捗報告フォーマット・失敗時リトライ手順・レビュー基準・依存関係）
否定形の誤読	「やらないで」と書いたことを実行される	Don’t を排除し肯定形で指示
要件スルー	コーディング規約が守られていない	重要事項を 3 回書く + CI (`mypy` 等) を必須にする
Slack Markdown 崩れ	箇条書きが消え指示が欠落	.md / .yaml ファイルを添付して渡す

ポジション	年収レンジ	リモート	求める人材
AIエンジニア	700–1,100万	フルリモート	LLM・画像認識・クラウドAI基盤を自走し「Devinを部下に」開発したい方
Tech Lead / BE・FEエンジニア	500–1,000万	フルリモート	Go/Python/TSでスケーラブルなWebプロダクトをガンガン作りたい方
インフラエンジニア	450–900万	フルリモート	AWS/GCP/IaCで土木DX基盤の信頼性を高めたい方
土木ブリッジエンジニア（BIM/CIM）	400–1,000万	フルリモート	3Dモデルと現場知見で開発チームと現場をつなぎたい方
PdM／PM	500–1,000万	フルリモート	Dev×Biz×現場ハブとして建設DXをリードしたい方

目次

1. はじめに ――「全部試せない問題」をどう乗り越えるか

2. 誰に向けた記事？／この記事でわかること

2‑1. 読者ターゲット

2‑2. 読み終わるとわかること

3. Devin Manager とは何者か ――API 連携とタスク分解の全体像

3‑1. “PM Devin” のワークフロー

3‑2. API ひな形

4. Prompt 設計フレームワーク ――再利用できる Manager／Worker テンプレ

4‑1. Manager テンプレ

4‑2. Worker テンプレ

4‑3. Promptの構成のテンプレート

5. 実戦 Tips ――“AI に AI 用プロンプトを書かせる”確実な回し方

6. つまずきポイントと解決策

7. これからの展望 ――Malme が描く「生成AI×土木DX」の次ステージ

8. 採用情報 ――“生成AIを部下にしたい”仲間を募集しています

Malme で得られること

Discussion

1. はじめに　――「全部試せない問題」をどう乗り越えるか