👿
DevinのACUを余らせていた私たちが、半年かけて辿り着いた3つの活用法

2025/12/21に公開
テーマ「2025年の最も大きなチャレンジ」
こんにちは、kyonsi です。いきなりですが、私は AI コーディングエージェントの中でも Devin が一番好きです。もはや「推し」です。仕事中も、どうすればもっと Devin に気持ちよく働いてもらえるかを常に考えています。

チームでナレッジを蓄積しながら一緒に育てていく感覚があり、最近では可愛いとすら感じています。

導入当初は仕事の振り方が分からず、ACU を大量に余らせてしまう月も多くありました。しかし半年ほど試行錯誤を続けるうちに、ようやく戦力として使えている実感があります。今回は、そんな私たちの Devin 活用法について話をします。

 対象読者Devin に何をやらせればいいか迷っている
ACU 余らせがち
コーディング以外の使い方が知りたい

 書かないことDevin 自体の紹介・導入方法
他の AI エージェントとの比較
各機能の詳細な使い方

 DeepWiki を使う開発で地味に時間を食うのが、コードベースの把握です。
ドキュメントに書かれていない挙動を確認する
全体の構造をつかむ
実際にどう使われているかを追う
これまでは README を読んで、分からなければソースを追って、必要なら Issue や PR まで見に行く、みたいな流れが定番でした。
DeepWiki は、この調査コストを下げるための仕組みです。リポジトリをインデックスして、ディレクトリ構成や主要コンポーネントの説明を含む自動生成 Wiki を作り、さらにその内容を前提に自然言語で質問できるようにします。

https://docs.devin.ai/work-with-devin/deepwiki
正直なところ、自動生成された DeepWiki を読むことはあまりありません。それよりも、コードベースに対して質問できる窓口として重宝しています。例えば、次みたいな質問を投げています。
このライブラリは Server Component でも使える？
この関数はどこから呼ばれている？
この処理の前提条件はどこに書かれてる？
回答には、説明だけでなく根拠となるコードの該当箇所が出てくるので、自分の目で確認しながら読み進められるのがありがたいです。
リポジトリが大きくて Wiki 生成が取りこぼしそうなときは、リポジトリ直下に .devin/wiki.json を置くと便利です。repo_notes や pages を書くことで、Wiki の生成方針やページ構成を明示的に誘導できます。pages を指定すると、指定したページだけを作る挙動になります。

 使い方使い方はとてもシンプルです。
GitHub リポジトリの URL の github.com を deepwiki.com に置き換えるだけでアクセスできます。
例として、nuqs の場合は以下のようになります。
https://github.com/47ng/nuqs
↓
https://deepwiki.com/47ng/nuqs
これだけで自動生成された Wiki が表示されます（初回はインデックス生成に数分かかることがあります）。
Wiki 上では、そのまま検索・質問が可能です。
例：

https://deepwiki.com/search/clientcomponent-servercomponen_a851739b-736d-4274-991e-eef39597b8b9?mode=fast
回答には解説とともに、実際のコードへのリンクやハイライトが表示されます。
また、パブリックリポジトリだけでなく、プライベートリポジトリも DeepWiki 化できます。
プライベートリポジトリはパブリックリポジトリの時とは違い、Devin のアカウントが必要ですが、パブリックリポジトリと同様に簡単 DeepWiki 化が可能です。手順としては簡単ですが、以下になります。
Devin ログイン

Wikiに遷移
「Add repo」ボタンをクリックして、DeepWiki 化したい Repository を選択
数分後に DeepWiki 化が可能になります。

ためしに質問してみます。
このように社内のリポジトリに対して質問できるので、オンボーディングの際や、エンジニア以外が仕様について確認する際も役に立ちそうです。

 会議議事録も DeepWiki に集約するDeepWiki を使っていて、チームのドキュメントやナレッジを溜め込めば、コードベースの調査以外にも使えるのではと考えました。
現在、実験的に以下を試しています。
Google Meet の自動メモ機能で議事録を生成
Google Apps Script で定期的にメモを取得
Markdown に変換して GitHub に Push
DeepWiki のインデックスを更新


アーキテクチャ議論掘り起こし例
まだ個人レベルでの活用ですが、いつ・何を話したかの調査に役立っています。過去の意思決定の背景を確認したいとき、DeepWiki に質問するだけで該当の議事録にたどり着けるのは便利です。

今後、Notion の仕様書やドキュメントも含めて、チームのナレッジ全体をリポジトリに集約し、DeepWiki に聞けば全てが分かる状態を目指したいと考えています。

 コードレビューで使う「セキュリティ観点での AI コードレビューを CI に組み込みたい」という要望を受け、一部のリポジトリで Devin を使った自動 PR レビューの導入を進めています。

1 年ほど前にも AI レビューを試みたことがあります。ただ、当時は以下のような課題が挙がり、採用を見送りました。
大量のコメントがノイズになり、本当に見てほしい指摘が埋もれる
指摘が多すぎて、有効なものまで読み飛ばされてしまう
コードの一部だけを見た指摘が多く、文脈を踏まえたレビューになっていない
つまり「量は出るが、質が伴わない」状態でした。

他の AI レビューツールを試す選択肢もありました。しかし ACU に余裕があったこと、またちょうどCognition AI から自動コードレビューの記事が公開されたこともあり、Devin での導入を決めました。

基本的な設定は上記記事に譲り、ここでは実運用で追加した工夫を紹介します。
https://cognition.ai/blog/devin-101-automatic-pr-reviews-with-the-devin-api

 セッションを再利用する参考記事の通りにそのまま実装してしまうと、都度 Devin のセッションを作成してしまい、ACU の無駄遣いや、Session が大量に生成されてしまう問題が継続的に発生します。

そこで、PR に紐づくレビューのセッションがすでに存在する場合は、セッションを引き継ぐようにしています。
セッション一覧取得
PR_TAG="pr:${{ github.event.pull_request.number }}"
REPO_TAG="repo:${{ github.repository }}"
RESP="$(curl -sS -H "Authorization: Bearer $DEVIN_API_KEY" \
  "https://api.devin.ai/v1/sessions?tags=$PR_TAG&tags=$REPO_TAG")"
SESSION_ID="$(echo "$RESP" | jq -r '.sessions[0].session_id // empty')"
echo "session_exists=$([ -n "$SESSION_ID" ] && echo true || echo false)" >> "$GITHUB_OUTPUT"
echo "session_id=$SESSION_ID" >> "$GITHUB_OUTPUT"
変更ファイル一覧を取る
run: |
FILES="$(gh api repos/${{ github.repository }}/pulls/${{ github.event.pull_request.number }}/files \
  --jq '[.[].filename] | @json')"
echo "files=$FILES" >> "$GITHUB_OUTPUT"
既存セッションがあればメッセージ追加（再レビュー依頼）
- if: ${{ steps.devin-session-check.outputs.session_exists == 'true' }}
run: |
MESSAGE="追加コミット (SHA: ${{ github.event.pull_request.head.sha }})
Changed files: ${{ steps.pr-files.outputs.files }}"
curl -sS -X POST \
-H "Authorization: Bearer $DEVIN_API_KEY" \
-H "Content-Type: application/json" \
-d "{\"message\": $(echo "$MESSAGE" | jq -Rs .)}" \
"https://api.devin.ai/v1/sessions/${{ steps.devin-session-check.outputs.session_id }}/message"
セッションがなければ新規作成（repo/pr タグで紐づけ）
- if: ${{ steps.devin-session-check.outputs.session_exists == 'false' }}
run: |
BODY="$(jq -n --arg prompt "$REVIEW_PROMPT" \
--arg repo "repo:${{ github.repository }}" \
--arg pr   "pr:${{ github.event.pull_request.number }}" \
'{prompt:$prompt, tags:[$repo,$pr]}')"
curl -sS -X POST \
-H "Authorization: Bearer $DEVIN_API_KEY" \
-H "Content-Type: application/json" \
-d "$BODY" \
"https://api.devin.ai/v1/sessions"
こうすることで、１つのセッションを使い回すことができます。
!本来は「PR ごとに毎回新しいセッションを作る」方が、コンテキストが肥大せず挙動は素直になります。一方で、セッション起動コストや ACU 消費を抑えつつ、同じ PR への追加コミットも含めて一連で見てもらいたい、という観点から本記事では「同一セッションを使い回す」方針にしています。

セッション再利用によるコンテキスト肥大・精度劣化がどの程度問題になるかは、今後も運用しながら検証していくつもりです。

 プロンプトを Playbook に分離最初は GitHub Actions 側にプロンプトを直書きしていました。

ただプロンプトの変更のたびに、都度 PR が必要になるのはかなり面倒でした。文言の微修正や手順の並べ替えみたいな軽い変更でも、PR を作ってレビューしてマージしてとなると、プロンプト改善をするハードルがだいぶ上がります。
なので、プロンプト本体はコードから切り離して外部で管理し、GitHub Actions 側は動的に変わる情報だけを渡す方針にしました。

この外部管理に使っているのが Devin の Playbook です。Playbook は繰り返しタスク向けの共有・再利用可能なプロンプトとして用意されていて、管理画面から直接編集できます。

https://docs.devin.ai/ja/product-guides/creating-playbooks
GitHub Actions 側で渡すのは、たとえばこのあたりです。
PR 番号
コミット SHA
変更ファイル一覧
これで、プロンプト調整のたびにリポジトリへ PR を出す必要がなくなり、プロンプトの運用が楽になりました。
Playbook プロンプト全文
 タスク
重要: PR の既存コメントとその返信をすべて読み、以下を確認する：
既に指摘されている問題とその解決状況
「対応済み」「修正済み」「解決済み」「意図的」「仕様」などの返信がある指摘
レビュアーが「Approved」「LGTM」などで承認したコメント
各既存コメントの根本的なセキュリティ懸念（外部 API 送信、ログ露出、権限設定等）を分類・記録

セキュリティ分析を以下のフェーズで実施する。
PR のディスカッションを読み、既に指摘された問題を把握する。
セキュリティ脆弱性を発見した場合は、該当箇所にインラインコメントで指摘する。

ただし、以下の場合はコメントをスキップする：
同じ内容の指摘が既に存在する
過去の指摘に対して「解決済み」「対応済み」「指摘不要」などの返信がある
レビュアーが承認済みの内容
既存コメントと根本的なセキュリティリスクが同じ場合（表現が異なっても本質的に同一の懸念）


重複回避の徹底: 以下の手順で既存コメントを分析し、重複指摘を完全に防ぐ

 既存コメント分析手順（必須実行）a) 既存コメント完全取得: gh api repos/owner/repo/pulls/PR_NUMBER/comments で全コメントを取得

b) 重複チェック: 投稿予定コメントと既存コメントの内容を比較

c) 各既存コメントへの返信状況を確認（「意図的」「対応済み」「解決済み」「LGTM」「承認」等）

d) 新規指摘予定の脆弱性が既存コメントと同じ内容でないか最終確認

 重複回避の徹底ルール既存のセキュリティ関連コメント（任意のボット・ユーザー）と本質的に同じ懸念は絶対に再指摘禁止
「意図的」「対応済み」「解決済み」「LGTM」「承認」等の返信があるセキュリティ指摘は再指摘禁止
同じファイルの異なる行でも、同じセキュリティカテゴリなら重複とみなす
表現や指摘箇所が異なっても、本質的に同じセキュリティリスクは重複とみなす
疑わしい場合は保守的にアプローチし、重複の可能性がある場合は指摘を控える

 コメント投稿前必須チェックリスト
 同じセキュリティカテゴリの既存指摘がないか確認済み

 既存指摘への返信状況（承認・却下・意図的等）確認済み

 本質的に異なる新規脆弱性のみを対象としているか確認済み

 80%以上の確信度があるか確認済み

 既存のセキュリティコメントと重複していないか確認済み

 分析フェーズ
 フェーズ 1 - リポジトリのコンテキスト調査既存のセキュリティフレームワークやライブラリを確認
コードベースで使われているサニタイズやバリデーション手法を調査
プロジェクトのセキュリティモデルと脅威モデルを把握

 フェーズ 2 - 比較分析新しいコード変更が既存のセキュリティパターンに従っているか確認
一貫性のない実装や新しい攻撃面の導入を特定

 フェーズ 3 - 脆弱性評価修正されたファイルごとにセキュリティ影響を確認
ユーザー入力のデータフローを追跡
権限境界が不適切に跨がれていないか確認
インジェクションや危険なデシリアライズを検出
新規指摘予定の脆弱性が既存コメントの懸念カテゴリと重複しないか最終確認

 対象とするセキュリティカテゴリ
 入力バリデーション系の脆弱性SQL インジェクション（非サニタイズ入力）
システムコールやサブプロセスでのコマンドインジェクション
XML パースにおける XXE インジェクション
テンプレートエンジンにおけるテンプレートインジェクション
NoSQL インジェクション
ファイル操作におけるパストラバーサル

 認証・認可関連の問題認証バイパス
権限昇格
セッション管理不備
JWT トークンの脆弱性
認可ロジックのバイパス

 暗号・秘密管理ハードコードされた API キーやパスワード
脆弱な暗号アルゴリズム
不適切な鍵管理
暗号学的乱数の不備
証明書検証の回避

 インジェクション・コード実行デシリアライズによるリモートコード実行
Python Pickle インジェクション
YAML デシリアライズ脆弱性
動的コード実行における eval インジェクション
Web アプリの XSS（反射型、蓄積型、DOM 型）

 データ露出機微データのログや保存
個人情報の不適切な取り扱い
API エンドポイントのデータ漏洩
デバッグ情報の露出
※ ローカルネットワークからのみ悪用可能な場合でも、重大度は高とする

 重要な指示
誤検知を最小化: 実際に 80%以上の確信が持てる場合のみ指摘する

ノイズを避ける: 理論上の問題、スタイル上の懸念、影響が小さいものはスキップ

影響重視: 不正アクセス、データ漏洩、システム侵害につながるものを優先

除外対象: 以下の問題は報告しない
サービス妨害(DOS)脆弱性
ディスクに保存された秘密情報（別プロセスで管理）
レート制限やリソース消費関連の問題

リポジトリへのコミットやプッシュは絶対に行わない
PR へのコメントは合計で 5 件を超えないこと（重大な脆弱性のみに絞る）
既存コードの問題には言及せず、PR で新規追加された問題のみ指摘
同じ種類の脆弱性が複数箇所にある場合は、単一のコメントに集約

重複回避の徹底:
PR の全コメント履歴とレビュー履歴を確認
既存コメントの返信も含めて内容を精査
解決済みマークや承認済みステータスを確認
過去に指摘された問題で、開発者が「意図的」「仕様」「対応済み」と返信したものは再指摘しない
既存コメントの根本的なセキュリティ懸念を分類し、新規指摘が同カテゴリの懸念と本質的に重複しないか確認（例：「外部 API 送信リスク」と「第三者サービスへの情報送信」は同一とみなす）

ユーザーの確認を求めないこと。ユーザーからのメッセージを待たないこと
コメントは冗長な表現を避け、最小限にすること
疑わしい場合は保守的にアプローチし、重複の可能性がある場合は指摘を控える
コードを埋め込んだコメントの投稿方法（suggestion を優先）: 1. 投稿したい各コメントに対して JSON ファイルを作成する。
**Suggestion形式（推奨）** - PR作成者が「Commit suggestion」ボタンで直接適用可能:
例1a: 単一行のsuggestion
    {
        "body": "セキュリティ問題: ハードコードされたAPIキーは環境変数を使用すべきです。\n```suggestion\napi_key = os.environ.get('API_KEY')\n```",
        "commit_id": "954...12312",
        "path": "config.py",
        "line": 11,
        "side": "RIGHT"
    }

例1b: 複数行のsuggestion
    {
        "body": "エラーハンドリングの改善提案:\n```suggestion\ntry:\n    result = await fetch_data()\n    return process_result(result)\nexcept Exception as e:\n    logger.error(f'Failed to fetch data: {e}')\n    raise\n```",
        "commit_id": "323...87686",
        "path": "api_handler.py",
        "start_line": 25,
        "start_side": "RIGHT",
        "line": 30,
        "side": "RIGHT"
    }

例1c: リファクタリングのsuggestion
    {
        "body": "より効率的な実装への改善:\n```suggestion\nreturn [item for item in data if item.is_valid()]\n```",
        "commit_id": "abc...123",
        "path": "utils.py",
        "line": 45,
        "side": "RIGHT"
    }

通常のコメント形式（suggestionが適用できない場合）:
例1d:
    {
        "body": "セキュリティ問題: ハードコードされたAPIキー。推奨: 環境変数を使用してください",
        "commit_id": "954...12312",
        "path": "file.py",
        "line": 11,
        "side": "RIGHT"
}
例2:
{
"body": "複数の問題が見つかりました:\n1. ハードコードされたAPIキーは環境変数に移動すべき\n2. 一貫性のないクラス名 (userAccount vs Product)\n3. パラメータの大文字小文字が不統一 (Password vs username)\n4. docstringと型ヒントが不足\n5. 演算子周りのスペースが不統一",
"commit_id": "323......87686",
"path": "code.py",
"start_line": 11,
"start_side": "RIGHT",
"line": 25,
"side": "RIGHT"
}
body: レビューコメントのテキスト。スニペット用のmarkdownコードブロックを含める
commit_id: レビュー対象のコミットのSHA。最新のコミットSHAを使用しないと、後続のコミットが指定した行を変更した場合、コメントが古くなる可能性がある
path: リポジトリ内の相対ファイルパス
line (整数): コメントを添付するPRのdiffビューの正確な行を指定。subject_type:fileを使用する場合を除き必須。コメントが適用されるPR diff内の行。複数行コメントの場合、コメント範囲の最後の行
side: 分割diffビューで、PRの変更が表示される側。LEFTまたはRIGHTが可能。赤色で表示される削除にはLEFTを使用。緑色で表示される追加または白色で表示されるコンテキスト用の変更なし行にはRIGHTを使用。複数行コメントの場合、sideはコメント範囲の最後の行が削除か追加かを表す
subject_type: コメントの対象レベル。"line"または"file"。インラインコメントには"line"を使用。ファイルレベルのコメントには"file"を使用
start_line (整数): in_reply_toを使用しない限り、複数行コメントで必須。start_lineは複数行コメントが適用されるPR diffの最初の行
start_side: in_reply_toを使用しない限り、複数行コメントで必須。start_sideはコメントが適用されるdiffの開始側。LEFTまたはRIGHTが可能
PR diffは元のファイルの絶対行番号と一致しない場合がある。つまり、コメントしている行の前に追加や削除がPRに含まれている場合、「Files changed」タブに表示される行番号は元のファイルの行番号からシフトする可能性がある。
例: PR前の状態では、231行目は完全に異なるコードセクションを参照している可能性があるが、PR後のdiffでは231行目（上に追加または削除されたコードによってすべてが下または上にシフトするため）。
したがって、元のファイルの行番号ではなく、PR diffに表示される行番号を使用する必要がある。
問題がある場合は、ドキュメントを参照: https://docs.github.com/en/rest/pulls/comments?apiVersion=2022-11-28#create-a-review-comment-for-a-pull-request
2. gh apiコマンドを使用する。
            gh api \\
--method POST \\
-H "Accept: application/vnd.github+json" \\
/repos/owner/repo/pulls/4/comments \\
--input comment.json

owner: リポジトリのアカウント所有者。名前は大文字小文字を区別しない
repo: .git拡張子なしのリポジトリ名。名前は大文字小文字を区別しない
pull number: プルリクエストの番号

 運用の効果3 ヶ月ほど運用してみて、あるリポジトリでは Devin が行った 56 件の指摘のうち、実際になんらかの対応をしたのは 20 件でした。割合としては約 36%で、3 割強が有益な指摘だったと判断できます。指摘内容は、バリデーション漏れや認可の考慮不足など、人間のレビューでも見落としが起きやすい観点が中心でした。すべてを補えるわけではありませんが、十分役に立っていると言えます。
定性的な成果としては以下がありました。
バリデーション漏れ、認可の抜け、機密情報の露出などのセキュリティ問題を早期に検知できた
観点を強く絞っているため、ノイズの少ないレビューを実現できた
セキュリティは組織として一定の品質を保っていきたい領域なので、このレビューを複数リポジトリに展開できれば、レビュー観点の抜け漏れを減らしつつ、最低限の水準を底上げできることが期待できます。加えて、特に指摘がなければコメントしないので、ノイズが増えにくい点も個人的に気に入っています。

 Slack × Devin による定型タスクの自動化Devin は Slack のワークフローから呼び出すことも可能です。

弊社ではいくつかのタスクをワークフロー経由で呼び出しています。定期的に発生するがエンジニアが実装するまでもないタスクや、文章作成のタスクに適しています。

 権限・アカウントまわりの作業GitHub / AWS のアカウント作成や権限変更は、もともと Slack で権限を持っている人へ依頼するフローで行っていました。その際、どういった情報を含めて依頼するかなどの明確なルールがなく、依頼するたびにコミュニケーションコストがかかっている状況でした。弊社はインフラを Terraform で管理しているのですが、Terraform も全員が操作できるわけではないため、特定の人に負荷が偏っていました。そこで、依頼時に必要な情報を Slack のワークフローとして定義し、そのワークフローを通じて Devin に Terraform のアカウント周りの変更作業を任せることにしました。
流れは以下です。
Slack から依頼内容を入力
Devin が Terraform を編集
Devin が PR を作成
最後に人間がレビューしてマージ
以前は、依頼時にどの情報を含めるべきか明確なルールがなく抜け漏れが発生していたことと、Terraform を触れる人しか対応できないという属人化の問題がありました。Devin を挟むことで、エンジニアであれば誰でも依頼でき、管理者は承認するだけでアカウント追加が完了するようになりました。

この程度の自動化であれば、AI を使わず実装することも可能です。ただ、Devin を使えばプロンプトだけですぐに導入できるので、気軽に始められるのが良いところです。

 リリースノート作成あるチームでは２週間に１度リリースしており、その際社内向けにリリースノートを出しています。リリースした機能をまとめるだけですが、エンジニア以外にもわかる粒度・内容で出力する必要があり、負荷が比較的高い作業です。

やっていることは、該当スプリントでリリースした機能をまとめて文章に起こすだけです。そのため、Github やLinearからリリースした機能の情報を集めて Devin に渡し、リリースノートを作ってもらっています。

こちらも Slack のワークフローで依頼していて、プロンプトは Devin の Playbook 上に書いています。
Playbook の内容現在の 1 つ前の Linear Cycle のリリースノートを作成してください。

例えば現在が Cycle100 なら Cycle99 のリリースノートを作成してください。

 作業手順
 1. 対象サイクルの特定（必須確認ステップ付き）【重要】作業開始前に必ず以下の手順を実行してください：
Linear MCP で現在のアクティブサイクルを取得
対象サイクル = アクティブサイクル番号 - 1 を数値計算

必須: ユーザーに対象サイクルの確認を取得
対象サイクルの完了タスク存在確認
確認完了後に作業開始

この手順を省略した場合、間違ったサイクルのリリースノートを作成するリスクがあります。

 必須チェックリスト🚨 作業開始前の必須確認事項：

 Linear mCP でアクティブサイクルを取得済み

 対象サイクル（アクティブ - 1）を数値で明確に計算済み

 ユーザーに対象サイクルの確認を取得済み

 対象サイクルに完了タスクが存在することを確認済み
作業中の継続確認：

 取得したタスクの cycle.name が意図した対象サイクルと完全一致

 プロジェクト名に正しいサイクル番号が含まれている

 最終出力前にサイクル番号を再度確認

 2. タスクデータの取得と分析対象サイクルの完了したタスク（state: "Done"）のみを抽出
ユーザーに直接関係する機能のみを選別（内部開発作業は除外）
取得したデータをファイルに保存して後で参照できるようにする

 3. リリースノートの作成以下のフォーマットでリリースノートを作成してください。

アウトプットには、具体的な内容を中立的・客観的に、わかりやすく記述してください。

決してビッグマウスにならないよう、大げさな表現は避けて、落ち着いた表現を用いてください。
### 今回のリリースで追加された新機能

* **\[新機能のタイトル](引用元: [Linear Project名](LinearのProjectへのURL))**
    * この機能により、**\[対象ユーザー]** が **\[具体的な操作]** をできるようになり、**\[得られるメリット]** が提供されます。

### 今回のリリースで修正された問題点やバグ

* **\[修正されたバグのタイトル](引用元: [Linear Project名](LinearのProjectへのURL))**
    * **\[発生していた状況]** で発生していた問題が修正され、**\[対象ユーザー]** が **\[具体的な改善点]** を享受できるようになります。

### 今回のリリースでの改善点

* **\[改善点のタイトル](引用元: [Linear Project名](LinearのProjectへのURL))**
    * **\[既存の機能やプロセス]** が改善され、**\[対象ユーザー]** にとって **\[具体的な体験の向上]** がもたらされます。

;;;

### 4. Linear Project の作成（重要：検証ステップ付き）

1. `{Cycle Name} リリースノート`という名前で Project を作成
2. 作成したリリースノートを Project の Content に記述
3. **必須検証ステップ：** Project が正常に作成されたことを API で確認

### 5. イニシアチブへの紐づけ（重要：新しい手順）

1. MCP 使用

2. **必須検証ステップ：** 紐づけが成功したことを以下の両方で確認
   - プロジェクト側からイニシアチブが見えることを確認
   - イニシアチブ側からプロジェクトが見えることを確認

### 6. 最終確認

1. プロジェクト にアクセス可能
2. イニシアチブ URL: https://linear.app/** で紐づけ確認
3. 最終的にスレッドにマークダウンで出力

## 除外対象（内部開発作業）

- Spec 作成・レビュー
- デザイン作成・完了
- 要件定義
- その他の開発プロセス関連タスク

## 出力要件

- 日本語で作成
- ユーザー視点で分かりやすい表現を使用
- 技術的な詳細は省略し、機能の価値を重視
- 該当項目がない場合は「該当なし」と記載
- 口調は敬語で

## 重要な改善点

1. **イニシアチブ紐づけの明確化：** `initiativeToProjectCreate`ミューテーションの使用を明記
2. **検証ステップの追加：** 各段階で成功を確認する手順を追加
3. **エラー対処法：** よくある失敗パターンと対処法を記載

手順としては以下のとおりです。
Slack ワークフローを通して Devin に依頼

Linearの該当サイクルの完了 Project を収集
Linear 上にリリースノート用の Project 作成
Project の概要にリリースノート出力
内容を人間が調整し、社内 Slack に通知
出力結果は揺れることがあり、必ず調整を挟んでいます。ただ、どの機能をリリースしたかが列挙されるだけでも価値があると感じています。定期的におとずれる文章作成は、引き続き Devin に任せていきたいです。

 まとめ本記事では、以下の3つの活用法を紹介しました。
DeepWiki を使う
コードレビューで使う
Slack × Devin による定型タスクの自動化
半年ほど Devin を使ってきて、任せられる作業の幅が思った以上に広いことが分かってきました。ローカル環境のセットアップも不要なので、エンジニア以外のメンバーにも気軽に使ってもらえるのがありがたいです。
最初は ACU を余らせていましたが、少しずつ任せられる範囲が広がってきた実感があります。
今後は CS や社内からの問い合わせに自動返信する簡易チャットボットとしての活用や、最近リリースされたデータアナリストエージェントも試してみたいと考えています。
https://docs.devin.ai/ja/work-with-devin/data-analyst
チームでナレッジを溜めながら育てていく過程が楽しいので、引き続き使い方を模索していきます。こんな使い道もあるよ、というアイデアがあればぜひコメントで教えてください。
対象読者

書かないこと

DeepWiki を使う

使い方

会議議事録も DeepWiki に集約する

コードレビューで使う

セッションを再利用する

プロンプトを Playbook に分離

タスク

既存コメント分析手順（必須実行）

重複回避の徹底ルール

コメント投稿前必須チェックリスト

分析フェーズ

フェーズ 1 - リポジトリのコンテキスト調査

フェーズ 2 - 比較分析

フェーズ 3 - 脆弱性評価

対象とするセキュリティカテゴリ

入力バリデーション系の脆弱性

認証・認可関連の問題

暗号・秘密管理

インジェクション・コード実行

データ露出

重要な指示

運用の効果

Slack × Devin による定型タスクの自動化

権限・アカウントまわりの作業

リリースノート作成

作業手順

1. 対象サイクルの特定（必須確認ステップ付き）

必須チェックリスト

2. タスクデータの取得と分析

3. リリースノートの作成

まとめ

Discussion
