Tines 3B か、他の製品か。8つの軸で見分ける

Last updated at 2026-10-25Posted at 2026-10-25

連載「Tines 3B を読み解く」の第11回（最終回）です。

はじめに

AI で自動化を作る製品は増え続けていて、そのたびに「Tines 3B は、何と比べて、どこが違うのか」と聞かれます。

けれど、製品名を並べて優劣を決めようとすると、たいてい議論が噛み合いません。前提にしている「作る人」と「守りたいもの」が違うからです。

この記事では製品の優劣は言いません。「何で比べるか」と「どんな場面で、どちらが向くか」を整理します。

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

3B と、ほかの自動化・AIエージェントの製品を比べる立場にある
比較表を作るとき、どの軸を置くべきか知りたい
3B が向く場面だけでなく、向かない場面も知りたい

先に結論です。製品は4つの分類に分けると見通しが良くなります。比べる軸は8つに固定し、軸の重みは顧客（自分たち）の状況から決めます。3B が第一候補になるのは、「多くの部門が AI で作り、IT が統治する」条件がそろうときです。そうでない場面では、ほかの製品が向くことが多くあります。

連載の中では、第1回〜第10回で見てきた3B の設計を、「他との比べ方」の形にまとめ直す回です。

他社製品については、各社の公式ページの記述を取得日つきで書きます。

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

比較表を作ったら、連携の数や「何分の1に短縮」のような数字が並び、何を比べているのか分からなくなった。
「記載なし」と書いたはずの欄が、いつの間にか「非対応」と読まれていた。
良い製品かどうかの話が、「うちの現場に合うか」の話と混ざってしまった。

どれも、「軸」と「前提」が決まっていないことから起きます。

結論：3つの見分け方

見分け方	何をするか	防ぐもの
分類を知る	製品を、4つの分類に分ける	性格の違う製品を、同じ土俵で比べること
8つの軸で見る	軸を固定し、各欄に出典と取得日を付ける	数字の印象と、「記載なし」の誤読
状況で選ぶ	顧客の状況から、先に評価する製品を決める	「どれが良いか」の、水掛け論

見分け方1：分類を知る

筆者は、製品を次の4分類に分けています。公式の分類ではなく、筆者の整理です。

分類	性格	例（調べた範囲）
A セキュリティ運用系	SOC（セキュリティ運用）の専任が、検知やチケットと一体で動かす	Torq、Splunk SOAR、Google Security Operations の SOAR など
B 汎用自動化系	業務部門が、多数のSaaSをつなぐ。ノーコード中心	n8n、Zapier、Make、Workato、Power Automate など
C エージェント構築系	AIエージェントを作って動かす基盤。焦点は製品ごとに違う	Copilot Studio、Retool、LangSmith など
D 自作	OSS や隔離の部品を組み、統制も自分で作る	LangGraph（OSS）、自作の構成

製品名は分類の例です。載せていない製品が劣っているわけではありません。

位置づけは、2つの軸で見ると分かりやすくなります。位置は筆者の判断で、優劣を表さず、機能の有無の判定にも使いません。

	ノーコード〜ローコード	コードファースト
SOC専用	A の多く
全社の業務部門	B の多く	3B（IT・セキュリティが統治）
業務部門〜開発者	C の多く	C の一部、D

補助の軸として「統制の自前度」があります。基盤が既定で提供してくれるものから、自分で用意するものまでの幅で、D は自分で用意する側の端です。

3B と位置が近いのは「全社で使い、コードが実体」の領域で、ここにはほかの製品も隣接しています。

見分け方2：8つの軸で見る

軸は次の8つに固定します。後から軸を選ぶと、特定の製品に有利になるからです。

軸	見ること	3B の整理（公式ドキュメントより）
認証情報	シークレットの保管先、コードや AI からの見え方、外部の保管庫との連携	コネクタに保管し、コードには現れない。外部の保管庫との連携は、確認できていない
実行の分離	生成コードやステップの隔離、外向き通信の制御	実行ごとの使い捨てのサンドボックス（gVisor）。宛先が一致しない通信は、既定で公開インターネットへ出る
監視・監査	監査ログの範囲、保持、転送、AI費用の見え方	監査ログ、Watchtower、ダッシュボード。保持期間の記載は、確認できていない
コードファースト	実体がコードか、画面上の構成か	実体は、スペース（Git リポジトリ）内のコード
モデル	AIモデルの選択、自社契約の持ち込み	有料プランで、複数のモデル提供元を接続できる
デプロイ	SaaS、セルフホスト、リージョン	SaaS とセルフホスト、Tunnel。セルフホストは x86_64 のみ
ガードレール	権限、承認（構築時か、実行中か）、上限	承認は構築時のもの。ライブの実行中に人の承認を挟む仕組みは、確認できていない
価格・契約	公開価格、課金の単位、認証・契約の範囲	Explore（無料）は公開。有料プランは、金額が非公開。認証の対象範囲は、確認できていない

右の列には、3B の弱みになりうる点も隠さず入れています。認証の範囲、実行中の承認、外部の保管庫、金額の非公開、日本語サポートやリージョンの未確認がそれです。一般提供の開始が2026年7月28日で実績が短いことも、比べるときの材料になります。

比較表を作るときの3つの約束

各欄に出典と取得日を付ける。他社の欄は、その会社の公式ページの記述に限ります。
「記載なし」を「無い」と書かない。取得できたページの範囲の話で、機能が無いこととは違います。
ベンダーの公表値は優劣の根拠にしない。連携の数や「短縮率」は、数え方や条件が違います。この記事の表にも載せていません。

もう1つ注意があります。「承認」という言葉は2つの意味で使われます。

構築時の承認: 作るときに、人が確かめる（3B の Plan mode、push live など）。
実行中の承認: 動いている最中に、人が確かめる。

顧客がどちらを求めているのかを先に聞いてください。これだけで比較の結果が変わることがあります。

公式が書いていること（例）

具体例を3つだけ挙げます。いずれも各社の公式ページが書いている事実の一部で、製品の評価ではありません。

製品	公式の記述（要旨）	取得日、ドメイン
Torq	外部のシークレットストアとして、HashiCorp Vault、AWS SSM Parameter Store、Azure Key Vault を使える	2026-10-08、kb.torq.io
Splunk SOAR（Cloud）	プレイブックの Prompt ブロックで、利用者や、SOAR を使わない個人・グループに確認を求め、応答を必須にして、返るまで進めない設計ができる	2026-10-14、help.splunk.com
Google Security Operations	手動アクションに承認リンクを付け、メールで、担当者や SOC のロールが承認・却下できる	2026-10-14、docs.cloud.google.com

この3つは、3B の「確認できていない」欄（外部の保管庫、実行中の承認）に重なります。比べるときは、こうした点を 3B 側の弱みとして正直に書く必要があります。

見分け方3：状況で選ぶ

分類と軸が決まったら、顧客の状況から先に評価する製品を決めます。「第一候補」は最初に評価するという意味で、優劣の断定ではありません。

状況別にまとめると、次のようになります。

顧客の状況	先に評価する製品	3B の扱い
SOC専任で、SIEM／ITSM と一体で動かしたい	分類A（既存の基盤に合わせる）	補完。SOC の外に広げる局面で比較
小さく、低価格で始めたい	分類B	Explore で試す。有料は金額が非公開
Microsoft 365 中心で、既存の統制に載せたい	Microsoft の自動化・エージェント系	併用か、対象外の業務で検討
基盤チームがあり、自作基盤が回っている	分類D（現行を継続）	足りない部品を補う用途で比較
全部門が AI で作り始め、IT が統治したい	3B	第一候補の1つ
認証範囲の書面、日本語サポートが契約前に必須	掲載が確かな製品	範囲が確認できるまで保留
実行中の人の承認が必須	文書化している製品	標準機能が確認できていない。実装できるかを確認

3B が差を出せるのは、次の3つがそろうほどです。

作り手が、少数の開発者に限られず、多くの部門に広がる。
シークレットを、コードや AI に見せたくない。
生成コードを、基盤の側で隔離して動かしたい。

逆に、1つも当てはまらないなら、3B を選ぶ理由は薄くなります。

3B が向かない場面（うまくいかない場面）

次の場面では、3B を第一候補にせず、確認が済むまで待つのが安全です。

認証の対象範囲の書面が、契約前に必須。3B が対象に含まれるかは確認できていません。
ライブの実行中に、人の承認が必須。3B の承認は構築時のものです。
日本語サポート、日本リージョン、SLA が必須。確認できていません。
金額が公開されないと、稟議が通らない。有料プランは金額が非公開です（Explore は無料で試せます）。
セルフホストを、Arm 環境だけで運用したい。3B は x86_64 のみです。
既存の製品で要件が満たせ、作り手も増えない。乗り換える理由が弱くなります。
SOC 向けの出来合いの部品が、すぐ必要。3B の標準部品の有無は確認できていません。

これらは 3B の欠点というより、「いまの条件では確認が済んでいない」点です。確認できた段階で、評価は変わりえます。

他のやり方との違い

「どれか1つに決める」必要はありません。併用と段階的な移行も、現実的な選択肢です。

状況	道筋の例
既存の SOAR／ITSM で足りている	既存を継続する。SOC の外の部門と、コードが実体の自動化を、3B で受ける
Microsoft 365 中心	M365 の中は現行の製品で、ほかのシステムと複数のモデルは、3B で。権限の二重管理を、先に決めておく
低価格の連携ツールを使っている	定型の連携は、そのまま。生成コードやシークレットの扱いが重い業務から、3B に移す
自作基盤がある	統制が足りない部分から、3B で置き換える。自作と3B の連携は、検証してから採用する
従来の Tines（Stories）を使っている	公式では、Stories と 3B の併用と、移行の支援が書かれている。規制対象のデータは、認証範囲が確認できるまで、慎重に

併用に共通する課題は、認証情報、監査ログ、権限が二重になることです。統合して見る手段の有無は確認できていません。

また、「3B だけ」とは言えません。隔離や、認証情報をコードに見せない設計は、ほかの製品や部品にもあります。3B の特徴は、作る・動かす・見るを、基盤の側から1つの環境で説明していることです。実際にどこまで効くかは、小さな試行で確かめてください。

他社情報の取得日と再確認

他社製品の記述は、2026年10月8日〜14日に取得したもので、一部は要約を介した確認にとどまります。この記事に載せた3製品（Torq、Splunk SOAR、Google Security Operations）の記述は、保存した公式ページの原文で確認しましたが、版や仕様は変わりえます。載せていない製品の現行の仕様は、ここでは扱っていません。

導入を検討するときは、使う行だけ、各社の公式ページで取得日以降の変更を再確認してください。

おわりに

製品を4つの分類に分けて、同じ土俵で比べないようにします。
8つの軸を固定し、各欄に出典と取得日を付けます。「記載なし」を「無い」と書きません。
顧客の状況から、先に評価する製品を決めます。併用も選択肢に入れます。

この連載は、3B を勧めるためのものではなく、「何を見て決めるか」を共有するためのものです。

連載の他の回

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

参考

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

Tines 3B pricing and packaging overview
Tines 3B Dictionary
実行環境、認証情報、セルフホストの各記事（第2回、第3回、第9回の参考を参照）

他社の公式ページ:

Torq: Integrate External Secret Stores with Torq
Splunk SOAR: Release notes（Splunk SOAR Cloud）
Google Security Operations: Assign approval links in actions

You get articles that match your needs
You can efficiently read back useful information
You can use dark theme

What you can do with signing up