連載「Tines 3B を読み解く」の第3回です。

はじめに

AI にワークフローのコードを書かせると、すぐにぶつかる問題があります。そのコードが外部サービスを呼ぶには APIキーやトークンが要ります。では、その鍵をどこに置くのか。

この記事では、2026年7月に一般提供が始まった AI ネイティブのワークフロー基盤「Tines 3B」がこの問題をどう設計しているかを、公式ドキュメントに沿って整理します。

こんな方に向けて書いています。

AI が書くコードや AI エージェントを、業務で動かすことを検討している
「APIキーは .env に置く」以外の選択肢を知りたい
製品の機能ではなく、設計の考え方を知りたい

先に結論です。3B は「コードにシークレットを持たせない」ことで、この問題に答えています。シークレット（APIキー、トークン、パスワードなど。公式の用語では「認証情報」）は「コネクタ」という入れ物にだけ置き、送信の瞬間にプロキシが宛先を確かめて付けます。

こんな場面、ありませんか

.env に APIキーを書いて、AI が書いたコードから読ませている。そのコードや実行ログに鍵が出ていないか、確かめきれない。
AI とのチャットに「このキーを使って」と鍵を貼ってしまい、チャットの履歴に鍵が残っている。
退職した人が作ったスクリプトがまだ動いている。どの鍵をどこで使っているのか、誰も把握していない。

共通するのは、「シークレットがコードや人の手の近くにある」ことです。コードが鍵を持つ限り、AI が書いたコードの1行、実行ログの1行、プロンプトの1回が漏えいの入口になります。

結論：3つの設計

3B の設計は、次の3つに整理できます。

設計	何をするか	防ぐもの
コードにシークレットを持たせない	シークレットはコネクタだけが持ち、送信の瞬間にプロキシが付ける	コード、環境変数、実行ログからの漏えい
宛先で縛る	認証は、コネクタの URL パターンに一致した宛先にだけ付く	鍵の、取り違えやリダイレクトによる送信
使う人と変える人を分ける	コネクタの権限を4つのロールに分け、共有は申請と承認	鍵に触れる人の、広がりすぎ

設計1：コードにシークレットを持たせない

シークレットの流れ

流れを図にしました。

ポイントは3つです。

コードはシークレットを一度も受け取りません。認証なしの要求を出すだけで、認証は実行中のコードと外部の間に立つプロキシが付けます。
外向きの通信は、すべて egress proxy を通ります。ステップは実行ごとに使い捨てのサンドボックスで動くため、プロキシの判断はサンドボックスの外にあり、コードからは上書きできません。
復号は送信の瞬間に、メモリの中だけで行われ、実行後に消えます。ディスク、環境変数、実行ログには書かれません。

保管の側も守りを重ねています。多くの認証情報は入力した端末で暗号化（HPKE）されてから送られ、保存には HPKE と AES-256-GCM、テナントごとの鍵を使います。データベースのコピーだけでは復号できない設計です。

コードの書き方

コードは通常のライブラリのままでよく、専用の SDK や手動のヘッダーは要りません。たとえば次のように書きます。

import requests

# 認証ヘッダーを、自分で付けない。
# 宛先が、コネクタの URL パターンに一致すれば、プロキシが認証を付ける。
response = requests.get("https://api.example.com/v1/items", timeout=10)
response.raise_for_status()
print(response.json())

この設計には、副次的な利点もあります。

無停止でローテーションできる。鍵の更新はコネクタの値を上書きするだけで、コードの再デプロイもワークフローの停止も要りません。
OAuth 2.0 の更新を任せられる。トークンの更新と期限の追跡は 3B が自動で処理します。

AI が書いたコードにシークレットが入らないのは、AI が賢いからではありません。コードがそもそもシークレットを受け取らない構造だからです。

設計2：宛先で縛る

認証を付けてよい宛先は、コネクタごとの「URL パターン」で決まります。Slack のトークンは Slack へ、社内 API のキーは社内 API へだけ送る、という境界です。

保護機能は3つあります。

保護機能	防ぐもの
Origin pinning	意図したサービス以外への、認証情報のリダイレクト
Principal scoping	マルチテナント環境での、テナント間の漏えい
SSRF 保護	クラウドのメタデータエンドポイントや、未許可の内部リソースへのアクセス

URL パターンは、必要最小のホスト（可能ならパスまで）に絞るのがよいでしょう。.* のような広い式にすると境界の意味が失われます。これは公式の記述ではなく、筆者の設計上の指針です。

なお、URL パターンの書式は公式の記事によって説明が異なります（単純なドメインの例は Connect to your tools by creating connectors、正規表現を前提にしたトラブルシュートは Troubleshoot common connector issues にあります）。使うときは、小さな検証用のコネクタで一致の挙動を確かめるのが安全です。

設計3：使う人と変える人を分ける

コネクタの権限は4つのロールに分かれています。

ロール	できること
Connector viewer	コネクタと、シークレットではない設定を見る
Connector user	ワークフローとチャットで、認証情報を使う
Connector editor	設定と認証情報を変える
Connector sharer	誰がアクセスできるかを管理する

「使う」権限と「認証情報を見る・変える」権限は別で、user は鍵の値を見ずに使えます。公式では「大半の人は user で足りる。editor と sharer は、管理する少数に」とされています。

共有は申請と承認で行います。editor だが sharer ではない人は、希望するアクセスをメモ付きで申請できます。承認するのはそのコネクタの sharer かテナント管理者で、自動で付与されることはありません。

つまずきやすい点が1つあります。スペース（ワークフローをまとめる単位）でコネクタを使うには、そのスペースにアクセスできる全員が、コネクタを使えることが条件です。1人でも使えないと、そのスペースでは使えません。

守ってくれないこと

設計が守る範囲と、利用者が担う範囲は別です。

チャットにシークレットを貼らないこと。「このAPIキーを使って」と書くのは、公式の悪い例です。「このステップを Stripe API に接続して」と書けば、3B がコネクタの設定を案内します。コードにシークレットが入らない構造でも、人がチャットに貼れば別の話です。
1度しか見えない鍵の保管。3B 自身を操作する鍵（個人の API キー、サービスアカウントのキー、SCIM のトークン、トンネルのトークン）は、作った瞬間にだけ表示されます。失くしたら作り直しです。
権限の設計。誰を user にし、誰を editor、sharer にするか。
セルフホストの暗号鍵。鍵の保管とバックアップは利用者の作業です。鍵を失うと、データベースが残っていても復号できません。自動のバックアップはありません。

他のやり方との違い

シークレットの扱い方を、一般的な分類で比べてみます（特定の製品の仕様ではなく、考え方の整理です）。

方式	シークレットの置き場	コードから値が見えるか	弱点
`.env`、環境変数	ファイルと、プロセスの環境	見える	AI が書いたコード、実行ログ、プロンプトインジェクションで漏れる可能性がある
シークレット管理から、実行時に注入	専用の保管庫	プロセスの中には値がある	保管庫は守れても、コードが値を持つ瞬間がある
プロキシ型（3B）	コネクタ（保管庫に相当）	見えない（通信の途中で付く）	宛先パターンの設計が要る。対応する認証方式に依存する

プロキシ型は「コードが値を持つ瞬間を無くす」考え方です。ただし万能ではありません。宛先の設計を誤ると境界の意味が薄れますし、人がチャットに貼る運用までは防げません。

おわりに

シークレットをコードに持たせず、送信の瞬間にプロキシが付ける。
認証は URL パターンに一致した宛先にだけ付ける。
使う人と変える人を分ける。

「AI が書いたコードにシークレットを持たせない」という考え方は、3B に限らず、これからの設計の参考になると思います。

連載の他の回

連載「Tines 3B を読み解く」（全11回）:

第1回 AIが作るコードの乱立に、どう備えるか。Tines 3B の全体像と5つの強みを読み解く
第2回 AIが書いたコードを、動かして大丈夫か。Tines 3B の実行とネットワークの分離を読み解く
第3回 AIエージェントに、APIキーを渡さない。Tines 3B の認証情報の設計を読み解く（この記事）
第4回 AIに、誰の権限で何をさせるか。Tines 3B の権限とガードレールを読み解く
第5回「誰が何をしたか」と「いくらかかったか」を、どう見るか。Tines 3B の監視・監査・費用を読み解く
第6回 AI にチャットで作らせても、実体はコード。Tines 3B の「コードファースト」を読み解く
第7回本番を壊さずに直す。Tines 3B のドラフトと本番、自己修復（Autofix、Autotune）を読み解く
第8回「ベンダーに縛られない」は、どこまで本当か。Tines 3B の接続口と、持ち出せる範囲を読み解く
第9回自社環境で動かすなら、何を引き受けるか。Tines 3B のセルフホストを読み解く
第10回契約の前に、何を書面で確かめるか。Tines 3B の導入・契約・費用を読み解く
第11回 Tines 3B か、他の製品か。8つの軸で見分ける

参考

公式ドキュメント（docs.3b.tines.com）: