結論から言うと、Cognitionは2026年8月7日付の公式リリースノートで、Devinのセキュリティプロファイル（ネットワークアクセスを統制する管理者機能）とパーソナルアクセストークン（PAT）（プログラマティック認証用のユーザー個人トークン）の2つを正式版（GA）にしたと発表しました。PATはメンバーがアカウントメンバーシップを失うと自動失効する仕組みを備えており、セキュリティプロファイルはセッションと自動化（automations）の両方に適用できます。この記事では一次情報にもとづき、2機能の中身と設計の考え方、CI連携の実務、同週に入ったautomations API v3 GA・GitLab対応・MCP OAuth改善までを整理します。
「PATのGA化なんて、APIキーの種類がもう1つ増えただけでしょ」──DevinのPAT正式化のニュースを見て、そう受け取った人は少なくないはずです。実はこの理解は的を外しています。今回のPATは単なる認証手段の追加ではなく、「メンバーがチームを離れた瞬間にトークンが自動で死ぬ」という失効設計を組み込んだガバナンス機能だからです。従来型のAPIキー運用で最も事故が起きやすいのは「退職者のキーが生き残る」局面ですが、DevinのPATはこの穴をプラットフォーム側で塞ぎにきました。
しかも同じ週のリリースノートには、ネットワークアクセスを管理者が一元統制する「セキュリティプロファイル」のGA化が並んでいます。つまり今回の更新は「認証（誰がDevinを呼べるか）」と「ネットワーク（Devinがどこに出ていけるか）」という、AIコーディングエージェントを企業導入するときの2大論点を同時に正式サポートした、と読むのが正確です。実際に社内でAIエージェントの導入支援をしていると、PoCから本番展開への壁になるのはモデル性能ではなく、ほぼ毎回この「アクセス制御をどう説明するか」です。順に見ていきましょう。
2026年8月7日のリリースで正式化された2つの機能
まず一次情報を押さえます。Cognitionの公式ドキュメント「Release Notes 2026」の8月7日付エントリで、次の2機能がGA（generally available、正式提供）になりました。
セキュリティプロファイル：管理者がネットワークアクセスを定義・適用
原文では「Security profiles are now generally available. Admins can define security profiles governing network access and apply them across sessions and automations」と記載されています。ポイントは2つあります。
- 管理者（Admin）がプロファイルを定義する──開発者が個々のセッションで場当たり的に設定するのではなく、組織側でネットワークアクセスのポリシーをテンプレート化できる
- セッションと自動化の両方に適用できる──人が対話的に使うDevinセッションだけでなく、トリガー起動される自動化ジョブにも同じ統制が効く
PAT：ユーザー個人としてのプログラマティック認証
同じエントリに「Personal access tokens are now generally available for authenticating with Devin programmatically. Tokens are automatically revoked when a user loses account membership.」とあります。つまりPATは、スクリプトやCIからDevin APIを叩くときに「サービスユーザーではなく自分自身」として認証する手段で、アカウントメンバーシップを失うと自動的に失効します。
| 機能 | 役割 | GA化で変わること |
|---|---|---|
| セキュリティプロファイル | Devinのネットワークアクセス統制 | 管理者定義のポリシーをセッション・自動化へ横断適用できる |
| PAT | ユーザー個人としてのAPI認証 | 正式サポートとなり、離脱時の自動失効が仕様として明記 |
なお「GA」はベータ・プレビュー段階を抜けて正式サポートに入ったという意味であり、この日に機能が初めて登場したわけではありません。評価導入中に「まだベータだから」と見送っていたチームにとって、稟議を通す条件が揃ったタイミングと捉えるのが実務的です。
ネットワーク統制の全体像──セキュリティプロファイルはどのレイヤーか
Devinのアクセス制御は、セキュリティプロファイル単体で完結するわけではありません。公式ドキュメントには複数の統制レイヤーが記載されており、それぞれ守る対象が異なります。混同しやすいので表で整理します。
| 統制レイヤー | 守る対象 | 公式ドキュメントの説明 |
|---|---|---|
| セキュリティプロファイル | Devinの外向きネットワークアクセス | 管理者が定義し、セッションと自動化に横断適用（2026-08-07にGA） |
| ドメインallowlist/denylist | サンドボックスから到達できるドメイン | 組織全体のリストを設定でき、設定時はサンドボックスのネットワークプロキシ経由でリスト内ドメインのみ到達可能。ユーザー個別の許可設定より優先される |
| IPアクセスリスト | Devinプラットフォームへの接続元 | エンタープライズ管理者がIP/CIDR単位で制限。リスト外IPからのAPIリクエストは401 Unauthorizedで拒否 |
方向で覚えると迷いません。IPアクセスリストは「入口」（誰がどこからDevinに接続できるか）、セキュリティプロファイルとドメインリストは「出口」（Devinがどの外部先に出ていけるか）の統制です。エンタープライズでの事故シナリオは大きく「外部から不正にDevinを操作される」と「Devinが意図しない外部先へデータを送る・不審なパッケージを取得する」の2系統に分かれるので、両方向にGAの統制手段が揃ったことになります。
出口統制の設計で実際にハマりやすい点をひとつ。ドキュメントのDesktop FAQには、ドキュメントサイト自体へのアクセスを維持するために「docs.devin.aiをallowlistに追加する」旨の案内があります。allowlistを絞り込みすぎると、パッケージレジストリやgitリモートといった開発に不可欠な到達先まで塞いでしまい、セッションが黙って失敗し続ける、という運用トラブルになりがちです。最初は「パッケージレジストリ＋自社gitリモート＋承認済みAPI」の最小セットから始めて、失敗ログを見ながら追加していく運用が現実的でしょう。
PATを使ったCI・自動化連携の実際
次にPAT側です。Devin APIの認証は公式APIリファレンスによるとBearerトークン方式で、ヘッダは次の形になります。
# Devin APIの認証ヘッダ（公式APIリファレンス記載の形式）
# 注意: 本番環境で使用する前に、必ずテスト環境で動作確認してください。
curl -H "Authorization: Bearer $DEVIN_API_KEY"
"https://api.devin.ai/v3/organizations/..."
v3 APIのベースURLは組織スコープがhttps://api.devin.ai/v3/organizations/*、エンタープライズスコープがhttps://api.devin.ai/v3/enterprise/*の2系統です。個別のエンドポイントパスとパラメータは更新が続いているため、実装時は必ず公式APIリファレンスの最新版を確認してください。
サービスユーザーキーとPAT、どちらを使うべきか
ここが設計の分かれ目です。Devinのプログラマティック認証には、PATのほかにサービスユーザーキー（cog_プレフィックスの credentials）があります。公式ドキュメントの記載を整理すると、使い分けはこうなります。
| 観点 | PAT | サービスユーザーキー |
|---|---|---|
| 認証の主体 | ユーザー個人。サービスユーザーもcreate_as_user_idも不要で、自分としてそのまま認証できる |
組織のサービスユーザー（cog_プレフィックス） |
| 他ユーザー名義の操作 | 不要（常に本人名義） | create_as_user_idで他ユーザー名義のセッション作成が可能。ロールにImpersonateOrgSessions権限が必要 |
| 失効 | アカウントメンバーシップ喪失で自動失効 | サービスユーザーのライフサイクル管理に従う |
| 向いている用途 | 個人のスクリプト、検証、本人に紐づけたい操作 | チーム共有のCIパイプライン、恒常的な自動化基盤 |
判断基準はシンプルで、「この処理は特定の人間に紐づくべきか、チームの基盤に紐づくべきか」です。個人の実験スクリプトをサービスユーザーキーで動かすと、誰の操作か監査で追いにくくなります。逆に、チームのCIをある個人のPATで動かすと、その人の退職と同時にパイプラインが止まります──後述するとおり、これは仕様どおりの挙動です。
X-Org-Idヘッダの要否
もう1点、公式ドキュメントには組織スコープのサービスユーザーキーは組織を自動解決する一方、エンタープライズのサービスユーザーキーとPATではX-Org-Idヘッダの指定が必要という記載があります。PATで叩いたら組織が特定できないエラーが返る、という場合はまずこのヘッダを疑ってください。
「離脱で自動失効」はなぜ重要か──よくある事故パターンと照らす
PATのGA発表文でCognitionがわざわざ1文を割いた「Tokens are automatically revoked when a user loses account membership」の意味を、ありがちな事故パターンと対で見てみます。
❌ 退職者のAPIキーが半年後も生きている
手動失効の運用では、オフボーディングのチェックリストから漏れたキーが残り続けます。SaaSごとにキー管理画面が分かれていると、棚卸しの網羅は現実的に困難です。⭕ DevinのPATはメンバーシップ喪失と連動して自動失効するため、この棚卸し漏れがプラットフォーム仕様として起きません。
❌ 共有キーを全員で使い回して、誰の操作か分からない
1本のキーをチームで共有すると、監査時に操作主体を特定できません。⭕ PATは本人名義の認証なので操作がユーザーに紐づき、組織的な自動化はサービスユーザーキー＋ImpersonateOrgSessionsで名義を明示する、という役割分担が成立します。
❌ チームのCIを個人のPATで動かしてしまう
自動失効は諸刃の剣でもあります。CIパイプラインを個人PATで組むと、その人の離脱でCIが突然死します。⭕ 恒常的な自動化はサービスユーザーキーに寄せ、PATは個人スコープの用途に限定する。「自動失効して困るものはPATに載せない」が設計原則です。
もう一歩引いて見ると、この「自動失効」はアイデンティティ管理の世界で言うライフサイクル連動型の権限剥奪（アカウント無効化と同時にアクセス手段が消える設計）を、AIエージェントのAPIトークンに適用したものと位置づけられます。人間のSSOアカウントは退職時に無効化されるのが当たり前になった一方で、機械的なアクセス手段であるAPIキーは長らくこの仕組みの外側に取り残されてきました。AIエージェントが人間の代わりにコードを書き、リポジトリに触れ、外部APIを叩く存在になった以上、その呼び出し手段にも同じライフサイクル管理を求めるのは自然な流れです。Devinが先行して仕様化したこの設計は、他のコーディングエージェント製品を評価するときの比較基準にもなるでしょう。
正直にお伝えすると、自動失効があってもトークン運用の課題がゼロになるわけではありません。有効期間中のトークンが漏洩すれば悪用リスクは残りますし、シークレットをどこに保管するかは依然としてチーム側の責任です。トークン保管・ローテーションの設計はAIエージェントのシークレット・クレデンシャル管理運用ガイドで詳しく扱っているので、あわせて参照してください。
同じ週に入ったその他の更新も見逃せない
2026年8月7日付のリリースノートには、GA化した2機能のほかに自動化まわりの更新がまとまって入っています。アクセス制御の話と地続きなので、要点だけ押さえておきます。
automations APIがベータからv3正式版へ
automations APIがベータを卒業し、本番のv3 API仕様に昇格しました。セッションをautomation_idでフィルタできるようになり、「この自動化が作ったセッションはどれか」をAPIで追跡できます。監査ログやコスト集計を自動化単位で切りたいチームには地味に効く変更です。
GitLabトリガー対応
自動化のトリガーとしてGitLabのissue、issueノート、push、パイプラインがサポートされ、issueトリガーへの返信（reply）と、GitLabのサービスアカウント接続にも対応しました。これまでGitHub中心だった自動化が、GitLab運用の組織でも組めるようになっています。
MCP接続のOAuth改善
MCP（Model Context Protocol）まわりでは、OAuth完了後にセッションが自動再開されるようになりました。従来はOAuthフローを挟むとセッションが中断したままになりがちでしたが、認可して戻れば作業が続きます。あわせて、個人のMCP接続はアカウント全体で有効になり（OAuthのスコープはインストール先組織に限定）、マーケットプレイスからのMCPインストールでカスタムサーバーURLを指定できるようになりました。MCP接続の認可設計そのものはAIエージェントのガバナンス・権限ポリシー設計で整理した考え方がそのまま使えます。
開発者への影響という観点でこの週の更新をまとめると、「Devinを1人の開発者のアシスタントとして使う段階」から「組織のパイプラインに組み込まれた実行基盤として使う段階」への布石が揃った週、と読めます。認証（PAT）、ネットワーク統制（セキュリティプロファイル）、自動化の本番API（v3）、GitLabという企業利用の多いプラットフォームへの対応、そしてMCPの認可体験改善──いずれも個人利用では困らないが、組織展開では必ず詰まるポイントばかりです。逆に言えば、この領域が正式化されたことで「セキュリティ要件を理由に見送っていた」チームは再評価の材料が増えたことになります。
導入チェックリスト
セキュリティプロファイルとPATを自社導入する際の確認手順です。上から順に潰していけば、少なくとも「統制の説明がつかない」状態は避けられます。
- 現状把握：Devinを呼んでいるスクリプト・CI・自動化を棚卸しし、それぞれの認証手段（PAT／サービスユーザーキー）と名義を一覧化する
- 認証の振り分け：個人用途はPAT、チームの恒常処理はサービスユーザーキーに振り分ける。個人PATで動くCIが残っていないか確認する
- セキュリティプロファイル定義：管理者がネットワークアクセスのポリシーを定義し、セッションと自動化の両方に適用する
- 到達先の最小セット確認：パッケージレジストリ・gitリモート・承認済みAPI・docs.devin.aiなど、開発に必須の到達先が許可されているかテストセッションで確認する
- 入口の統制：エンタープライズ利用ならIPアクセスリストの設定を検討する（リスト外IPからのAPIリクエストは401で拒否される）
- X-Org-Id対応：PAT・エンタープライズキーで叩くコードに
X-Org-Idヘッダを入れる - オフボーディング手順の更新：PATは自動失効するため手動作業は不要になるが、「PATで動いていた個人の自動処理が止まる」影響確認を退職フローに追記する
- 監査の紐付け：automations API v3の
automation_idフィルタを使い、自動化ごとのセッション追跡を監査手順に組み込む
よくある質問
Q. セキュリティプロファイルとPATは、どちらか片方だけ導入しても意味がありますか？
あります。守る対象が別物だからです。PATは「誰がDevinを呼べるか」という認証の統制、セキュリティプロファイルは「Devinがどこへ出ていけるか」というネットワークの統制です。ただし企業導入の説明責任という観点では、入口と出口の両方を揃えて初めて一貫したポリシーになるため、最終的には両輪での運用を推奨します。
Q. 既存のサービスユーザーキー運用からPATに全面移行すべきですか？
全面移行は推奨しません。PATは個人名義の認証であり、メンバー離脱で自動失効します。チーム共有のCIや恒常的な自動化を個人PATに載せると、離脱と同時に止まります。個人スコープの処理はPAT、組織スコープの処理はサービスユーザーキー、という併用が公式ドキュメントの設計とも整合します。
Q. GA化前からベータで使っていた場合、何か作業は必要ですか？
リリースノート上、既存利用者向けの移行手順は8月7日付エントリには記載されていません。ただしautomations APIはベータから本番v3仕様への昇格という変更を含むため、automations APIを叩いている実装がある場合はv3仕様との差分を公式APIリファレンスで確認しておくのが安全です。
要点の整理
- 2026年8月7日、Devinのセキュリティプロファイル（ネットワークアクセス統制）とPAT（個人のプログラマティック認証）がGA化した。一次情報はCognition公式リリースノート
- PATはアカウントメンバーシップ喪失で自動失効する。退職者キーの残存という定番事故を仕様レベルで防ぐ一方、チームのCIを個人PATに載せてはいけない
- 認証はBearer方式。組織スコープは
api.devin.ai/v3/organizations/*、エンタープライズは/v3/enterprise/*。PATとエンタープライズキーはX-Org-Idヘッダが必要 - ネットワーク統制はセキュリティプロファイル（出口）・ドメインallowlist（出口）・IPアクセスリスト（入口）の多層構造で捉える
- 同週にautomations API v3 GA（
automation_idフィルタ）、GitLabトリガー、MCPのOAuth自動再開・カスタムサーバーURL対応も入った
Devin自体の導入手順や全体像はDevin完全ガイドを、直近のモデル・製品動向はSWE-1.7とWindsurf移行の解説記事をどうぞ。
参考・出典
- Devin Release Notes 2026（Cognition公式・2026年8月7日エントリ）──セキュリティプロファイル／PATのGA化、automations API v3、GitLab対応、MCP改善の一次情報
- Devin API Reference Overview（Cognition公式）──Bearer認証、v3ベースURL、サービスユーザーキーとPATの関係、ImpersonateOrgSessions権限
- IP Access Lists（Cognition公式）──IP/CIDRによるプラットフォームアクセス制限と401拒否の仕様
- Devin Recent Updates（Cognition公式）──最新の更新情報一覧
この記事を読んで導入イメージが固まってきた方へ
UravationではAIエージェント導入の研修・コンサルを行っています。
著者：佐藤傑（さとう・すぐる）。株式会社Uravation代表取締役。X（@SuguruKun_ai）フォロワー約10万人。100社以上の企業向けAI研修・導入支援。著書『AIエージェント仕事術』。
