Foundryのコード型エージェントに権限付きテンプレートと公開API

Palantir Foundryは、コード型エージェントの作成から公開までを簡略化しました。Ontology SDK、Ontology MCP、Palantir MCPへ範囲を限定した権限で自動認証し、クライアントID、秘密情報、Foundryトークンを手作業で渡す必要をなくします。

要点

• ClaudeエージェントSDK、OpenAIエージェントSDK、Googleエージェント開発キット向けのテンプレートが用意され、SDK・MCP設定と案内手順を含みます。
• 公開時にOntologyとの紐付けとエージェントAPI名を設定し、追加構成なしでWorkshopとOntology SDKから呼び出せます。
• ContinueからPalantir MCPを使い、エディター内でエージェントに付与するSDK・MCPの範囲を管理できます。

今回の更新で変わること

Foundryのコード型エージェントは、大規模言語モデルをFoundry内のデータとツールへ接続する開発方式です。Ontologyの読み書き、失敗したビルドの修正、従来システムのFoundry移行など、参照だけでなく変更を伴う用途も想定されています。今回の更新はモデル能力ではなく、認証、雛形、公開後の呼び出しを共通化します。

最も大きい変更はツール認証です。エージェントはOntology SDK（OSDK）、Ontology MCP（OMCP）、Palantir MCPに対し、設定された範囲の権限で自動認証します。以前のようにクライアントID、クライアント秘密情報、Foundryトークンをコードや設定へ手作業で渡す必要がありません。秘密情報の配布を減らせますが、付与範囲が適切かの確認は引き続き必要です。

作成時には、ClaudeエージェントSDK、OpenAIエージェントSDK、Googleエージェント開発キット（ADK）の各テンプレートを選べます。各雛形にはOntology MCP、Palantir MCP、Ontology SDKクライアントの簡略化された構成が含まれ、共通設定はライブラリ側へ移されています。作成後は案内手順が次の作業を示すため、認証や接続の定型部分を毎回組み立てずに済みます。

公開するエージェントには、Ontologyとの紐付けとエージェントAPI名を設定します。これにより、関数をWorkshopとOntology SDKの両方から追加設定なしで呼び出せます。公開名は業務アプリから参照される契約になるため、実装名のように頻繁に変えず、入力・出力、権限、版の互換性を管理する必要があります。

開発環境では、ContinueとPalantir MCPを組み合わせられます。エディターから自然言語でエージェントを構築しながら、そのエージェントへ付けるSDKとMCPの範囲を管理します。雛形によって接続が簡単になっても、モデルへ渡すツールを無制限に増やすべきではありません。用途ごとに読み取り、書き込み、管理操作を分離します。

公式発表は、エージェントがOntologyデータを読み書きできると説明しています。書き込み操作では、対象オブジェクト、許可された変更、確認が必要な条件、重複実行時の挙動を決めます。失敗したビルドの修正では、差分確認と試験を通してから統合し、システム移行では変換結果と件数を検証します。

複数のSDK向けに同じ開発導線ができることは、モデルや提供者を選びやすくします。一方、Claude、OpenAI、Googleのエージェント実行が同じ挙動・ツール呼び出し・費用になるわけではありません。共通の業務評価を用意し、権限逸脱、失敗時の再試行、長時間処理、出力の再現性を比較します。

今回の項目は認証の自動化と公開導線を説明しており、監査ログ、評価、承認、実行上限のすべてが自動設定されるとは述べていません。開発速度が上がるほど、雛形から作ったエージェントを誰が公開できるか、API名を誰が変更できるか、利用中の版をどう追跡するかを組織側で定める必要があります。

対象になりそうなユーザー・チーム

Foundry上でコード型エージェントを作る開発者、Ontology・MCPの権限を管理するプラットフォーム担当、WorkshopやOSDKからエージェントを使う業務アプリチームが対象です。

押さえておきたいポイント

• 雛形が要求するOntology SDK、Ontology MCP、Palantir MCPの範囲を確認する。
• クライアント秘密情報が不要になった後も、古い設定や保存済みトークンを残さない。
• Ontologyとの紐付け、API名、入力・出力、利用版を公開台帳へ記録する。
• 読み書き操作、再試行、承認、監査、停止をSDKごとに同じ条件で試す。

実務へのつながり

一つの雛形から読み取り専用エージェントを作り、必要最小限のOSDK・MCP範囲だけを与えます。Ontologyへ紐付け、安定したAPI名で公開し、WorkshopとOSDKから同じ入力を呼び出します。その後、拒否されるべき操作、権限変更、版更新、呼び出し元の監査記録を確認してから書き込み用途を検討します。

結局、この更新をどう見るべきか

今回の更新は、複数SDKの雛形、範囲付き自動認証、Ontologyとの紐付け、公開API名を一つの開発導線へまとめます。秘密情報の手動配布を減らし本番化を速める一方、付与権限、公開契約、書き込み操作、版管理を明示的に確認する必要があります。