第２回：「作るより、買うが正解」開発工数4割削減を叶えた、Tactnaの狂気的なインフラ思想

TL;DR（超要約）

• 自社で認証・管理機能を開発すると、高額な維持費（年2,000〜3,000万円）やセキュリティリスクが発生します。
• 開発工数の30〜40%を占めるアカウント・権限管理機能をTactnaで「買う」方が、自作するより圧倒的にコスト効率が良い（年間数百万円）です。
• 開発者権限の時間制限や、特定顧客のみのデータ復旧が可能な二層DB構造など、堅牢な運用体制を構築しています。
• ISO認証を取得し、安定性を最優先した「枯れた安全な技術」（AWS ECSなど）で、安心してコアなビジネス開発に集中できます

はじめに：なぜ今、「基盤の裏側」を語るのか

こんにちは、TC3のコーポレート部の麻生です。

前回の座談会では、弊社CEOで「Tactna」プロダクトオーナーの須藤と、開発責任者の眞田が、認証（Authentication）をIDaaSに委ねた後の「ユーザー管理（Post-CIAM）」こそが、現代のアプリケーション開発における最大のボトルネックであると提言しました。

今回は、この課題をさらに深掘りし、システムの中でも特に見落とされがちな「裏側」に潜む問題に迫ります。

「管理画面なんて、自社のエンジニアがサクッと作れば済む話でしょ？」

開発者なら誰しも、そう考えたことがあるかもしれません。しかし、この判断こそが、気づかないうちに「終わらない運用コストの増加」や、ビジネスを揺るがす「セキュリティ上の大きな穴」を生み出す原因になります。

そこで今回は、眞田に加え、Tactnaの開発・インフラ責任者である江崎が、自社プロダクトであるTactnaの“ブラックボックス（裏側の仕組み）”を包み隠さずオープンに語ります。

現場をよく知る彼らが、「Build（自社開発） vs Buy（SaaS利用）」という開発戦略の根幹を揺るがす問いに、具体的な解決策を提示します。

人為的なミスを徹底的に排除する思想

麻生： 今回は、社内に大規模な開発部隊を持たない企業の事業責任者やリーダーの方々に向けて、Tactnaのインフラやセキュリティが、一般的な「自社開発（スクラッチ）」と具体的にどう違うのかを聞いていきたいです。

江崎： 最大の違いは、「エラーが起きにくく、人為的ミスを徹底的に排除する構成」になっているか否かです。

我々のインフラはTerraformですべてコード化（IaC）されており、アプリケーションのデプロイもCI/CDパイプラインで完全自動化されています 。これにより、手作業による設定ミスや、本番環境と検証環境の構成差異といったリスクを根絶しています。

一般的な受託開発や、納期に追われる社内プロジェクトで、ここまで厳密な自動化と品質管理を徹底できているケースは、正直なところ稀だと思います。

眞田： そうですね。特に強調したいのは、我々が提供しているのが単なる「Webアプリ」ではなく、その下の「プラットフォーム」だという点です。

Tactnaの上にはお客様の重要なアプリケーションが乗り、さらにその先にはお客様の顧客データが存在します。そのため、一般的なアプリ開発よりも2段階ほど深いレイヤーで、モジュール単位での厳格なデプロイ制御を行っています 。

江崎： 内部の話をすると、開発者が本番環境にアクセスする際の権限管理も徹底しています。AWS OrganizationsでアカウントごとにRoleを細かく割り振っているのはもちろん、付与した権限は時間制限付きで、一定時間が過ぎると自動的に消滅する仕組みを入れています 。

麻生： 権限が勝手に消えるんですか？

眞田： はい。一般的なスタートアップや社内ツール開発では「面倒だから」と省略されがちな部分ですが、我々は「認証基盤」というセキュリティの要を提供している以上、内部犯行や誤操作のリスクをゼロに近づける義務があります。ここまでコストをかけて「守り」を固めている点が、自社開発との決定的な差です。

インフラの狂気：「テナント分離アーキテクチャ」

眞田： ここで注目してほしいのが、Tactnaの「テナント分離アーキテクチャ」です。

通常のSaaS（マルチテナント）は、コスト効率を優先して1つのAWSアカウント・DBの中に全顧客のデータを混ぜて管理します（論理分離）。しかし、Tactnaはお客様ごとに専用のAWSアカウントを発行し、ネットワーク経路ごと物理的に分断しています 。

江崎： これ、運用側からすると正直「狂気」に近い構成なんですよ。導入当初、私は猛反対しました。「管理が大変すぎる」と。

アカウントが増えれば増えるほど監視対象も増えますし、デプロイも複雑になります。でも、セキュリティと「影響範囲の極小化」という観点では、これ以上の解はないんですよね。

麻生： 具体的に、お客様にはどういうメリットがあるんですか？

江崎： お客様ごとに「入り口」が違うので、他のお客様の通信が混ざることが物理的にあり得ない。例えば、あるお客様がカスタマイズ（Extension）で重い処理を書いてサーバーに負荷をかけてしまったとします。論理分離だけのSaaSなら他のお客様も巻き添えになりますが、Tactnaなら「影響が出るのはそのお客様の環境だけ」で済みます 。他社には一切迷惑をかけません。

眞田： ログ管理に関しても同様です。共有環境にログを混ぜるのではなく、お客様ごとの環境に個別にログを残しています。万が一、ログの中に機密情報が含まれてしまったとしても、他のお客様からは絶対に見えません 。

江崎： さらに、解約時のデータ処理もクリーンです。テナント単位でリソースが完全に分離されているので、「データを消してくれ」と言われた際も、そのAWSアカウントごとリソースを削除すればよく、データの残留リスク（ゴミが残るリスク）がありません 。

眞田： 普通はここまでやりません。コストと手間がかかりすぎるからです。でも、「自社でそこまで作れますか？」という話なんです。

事業会社が自社サービスのために、ここまで堅牢で隔離されたマルチテナント基盤をスクラッチで組むのは、ROI（投資対効果）が全く合いません。だからこそ、Tactnaという「完成された基盤」を買う意味があるんです。

自社開発か、サービス利用か。コストパフォーマンスは？

麻生： セキュリティが凄いのは分かりました。でも、ビジネスサイドからするとやはり「コスト」が気になりそうですね。「自社で作ったほうが安上がりじゃないか？」という声に対してはどう答えますか？

眞田： 結論から言うと、「自社で作るほうが圧倒的に高くつく」というのが真実です。

我々の経験則ですが、B2B SaaSを開発する際、アプリケーション全体の開発工数の約30〜40%は「アカウント管理・権限管理」の部分が占めます 。

コア機能を作る前に、認証、招待、権限設定、退職処理...といった地味な機能の開発に、予算と時間の約4割が消えているんです。アプリによっては6〜7割を占めることさえあります。

江崎： さらに恐ろしいのは、作った後の「維持コスト（ランニングコスト）」です。

例えば、サーバーのTLS証明書更新。昔は1年単位でしたが、最近はセキュリティ基準が上がり、1ヶ月単位や3ヶ月単位での更新が求められることもあります 。

OSのパッチ当て、ライブラリの脆弱性対応、AWSの仕様変更への追従...。これらを自社でやり続けるには、最低でも専任のインフラエンジニアが数人は必要です。

眞田： 試算してみると、Tactnaのライセンス費が年間数百万円だとして、自社で同等のセキュリティと機能を維持するためにエンジニアを2〜3人雇ったら、人件費だけで年間2,000〜5,000万円はかかります。しかも、採用難易度の極めて高いセキュリティ人材です。

「数百万円で安心・安全を買う」か、「数千万円かけて自社で苦労とリスクを買う」か。 経営判断としては明白ではないでしょうか 。

バックアップと「データ復旧」の現実解

麻生： データの安全性についても聞かせてください。万が一の障害やデータ破損の時、どうやって復旧するんですか？

江崎： バックアップは1時間単位などで定期取得しています。特徴的なのは、先ほどのマルチアカウント構成の話とも繋がりますが、「共有DB（Shared）」と「顧客個別DB」の2層構造になっている点です 。

眞田： 通常のSaaSでは、全顧客のデータが1つの巨大なDBに入っているため、「A社が操作ミスでデータを消したから戻してほしい」と言われても、おいそれとは戻せません。DB全体を巻き戻すと、B社やC社のデータまで巻き戻ってしまうからです。

しかし、Tactnaはお客様個別の領域（カスタムモジュール等）に関してはDBが分かれているため、「特定のお客様だけデータをリストアする」という対応が技術的に可能です 。

麻生： それは安心ですね。逆に、弱点というか、正直に伝えておくべき制約はありますか？

江崎： 正直に言うと、Active/Active構成のような完全無停止ではありません。CognitoやAuth0といった連携先IDaaSの仕様上の制約もあり、災害時には復旧まで数時間かかる可能性はあります 。

しかし、我々のターゲットは「人命に関わるミッションクリティカルなシステム」ではなく、企業のDXを支えるB2B SaaSです。コストと可用性のバランスを冷静に見極め、過剰投資を避けつつも、「個別に復旧できる」という実用的な安心感を提供しています。

「枯れた技術」を選ぶ勇気と、第三者認証の重み

麻生： 江崎さんはインフラ責任者として、技術選定でこだわっているポイントはありますか？

江崎： 意外かもしれませんが、「Kubernetesを使わない」ことですね 。

エンジニアとしては新しい技術や流行りのKubernetesを使いたくなるものですが、我々の規模や用途ではオーバースペックであり、運用コストが無駄に跳ね上がります。

代わりにAWS ECS（Elastic Container Service）を採用しています。シンプルで、管理がしやすく、十分にスケールする。「枯れていて、安全で、スケールする技術」しか使いません。技術者としての「遊び」や「エゴ」を捨てて、お客様にとっての「安定性」と「コスト効率」を最優先しています 。

眞田： その積み重ねの結果として、TactnaはAWS FTR（Foundational Technical Review）を通過し、ISO 27001 / 27017も取得しています 。

これらは、「ちゃんとしてます」という自己申告ではなく、第三者が裏側のブラックボックスを監査し、「合格」を出した証明です。

自社開発した管理画面に対して、わざわざ数百万円かけて監査を受ける企業は稀でしょう。Tactnaを採用すれば、この「お墨付き（Audit）」もセットで手に入ります。監査コストや説明責任を、我々にアウトソースできるわけです。

結論：「車輪の再発明」を止める決断を

麻生： 最後に、この記事を読んでいるみなさんにメッセージをお願いします。

江崎： インフラ屋として言えるのは、「餅は餅屋」です。認証やインフラ周りは、ミスが許されない上に、差別化にもなりにくい領域です。そこは我々のような専門家に任せて、皆さんはアプリケーションのコア機能の開発、つまり「顧客への価値提供」にリソースを全振りしてください 。

眞田： 多くの企業が、認証基盤を「とりあえず」で作ってしまい、後から拡張性やセキュリティの問題で手戻りが発生しています。

Tactnaは、「未来のビジネスの変化（マルチアプリ化、AIエージェント対応など）」に耐えうるアーキテクチャを、サービス形式で提供するものです。

「認証・ID管理機能は作るものではなく、買うもの」。このパラダイムシフトを受け入れることが、プロジェクトを成功させ、ビジネススピードを加速させる最短ルートだと確信しています。

編集後記：

今回の対談では、Tactnaのインフラ・セキュリティの深層に迫りました。

「マルチAWSアカウントによる物理分離」「開発者権限の自動消滅」「Kubernetesを使わない質実剛健な技術選定」。これらはすべて、お客様のビジネスを守り、無駄なコストを発生させないための、TC3のエンジニアたちの職人芸とも言えるこだわりです。

「自社のエンジニアを、管理画面のメンテ係にしていませんか？」

この問いにドキッとした方は、ぜひ一度Tactnaの導入をご検討ください。

検討にあたって検討項目を解説したガイドブックを無料で配布中です。

こちらもぜひご確認ください。