OCI運用を劇的に楽にしたい！統合管理ツール自作の記録（第1回：構想編）

2026.10.27

こんにちは。FREEDIAでOCIを担当している小林です。

今回は、私たちが開発している OCI（Oracle Cloud Infrastructure）統合管理ツール「OCI Manager（仮）」 について、なぜこのツールを作ろうと思ったのか、何を目指しているのかという「構想編」をお届けします。

OCIは、Oracleが提供するクラウドサービスです。ほかの主要なクラウドと比べてコストを抑えやすいのが大きな魅力で、私たちも複数のプロダクトや案件で活用しています。OCIについては、下記の動画もぜひご覧ください。

1. 開発の背景と現場のリアルな課題
- 複数テナントとIaCの壁
- 見えない利用状況
2. ツールのコンセプトとコア機能
3. 独自メソッド「FEARIDE」によるAIドリブン開発
4. 今後の展望と次回予告
- 社内ツールから、サービス展開へ
- 次回予告

1. 開発の背景と現場のリアルな課題

複数テナントとIaCの壁

私たちはプロダクトや案件ごとにOCIのテナンシやコンパートメントを分けて運用しています。セキュリティや請求の観点では正しい分け方なのですが、運用する側としてはこれが地味に面倒です。

あるリソースの状態を確認したいだけなのに、Aのテナントにログインして確認し、ログアウトしてBにログインし直して……という往復が日常的に発生します。1回1回は数分でも、積み重なると無視できない負荷です。

さらに悩ましいのがIaCです。IaC（Infrastructure as Code）とは、サーバーやネットワーク、データベースといったインフラの構成をコードで記述し、そのコードをもとに環境を構築・管理する考え方です。手作業での構築と違い、同じコードから何度でも同じ環境を再現でき、変更の履歴もコードとして残せるのが大きなメリットです。OCIでは、IaCのツールとしてTerraformがよく使われます。

ただ、IaCが理想なのは分かっていても、プロダクトや案件ごとにTerraformのコード（tfファイル）を手作業で書くのは時間がかかります。

「それならAIにコードを書かせればいいのでは？」とも考えましたが、AIに直接構築させると再現性の担保やコストの課題が残るため、IaCのメリットを活かしたまま自動化するアプローチを重視しました。

見えない利用状況

もうひとつの課題は、管理者側の悩みです。

社内でOCI環境を管理する立場では、今どのリソースが動いているのか、コストがどれくらいかかっているのかを知りたいとき、トータルが分かりづらいのでそのたびにインフラ担当へ確認しています。各プロダクト側にも管理者や担当者がいますが、自分で確認しようにも、OCIを触るのは初めてという方もおり、全員が使いこなしている状況ではないのが実情です。私自身も管理者として同じもどかしさを感じていましたし、ほかの管理者からもこんな声を何度も聞いてきました。

「今どのサーバーが動いているのか、コストがどう推移しているのか、どこを見ればいいのか分からない」

OCIコンソールは高機能ですが、その分メニューが多く、慣れていない人が必要な情報にたどり着くのは簡単ではありません。しかも前述のとおりテナントが分かれているため、全体像を把握するにはさらにハードルが上がります。

「インフラ担当にとっても、管理者にとっても、OCIの状況がひと目で分かる場所が欲しい」。これが出発点でした。

2. ツールのコンセプトとコア機能

まずは自分たちのために

最初に決めたのは、「まずは自分たちが毎日使うツールにする」ということです。

いきなり汎用的な製品を目指すと、機能が膨らんで何も完成しない、ということになりがちです。そこで、インフラ担当と管理者という、実際に痛みを感じている当事者のペインを解消することに集中しました。自分たちで毎日使えば、使いにくい箇所はすぐに分かります。

統合ダッシュボード＆コストビュー

コア機能のひとつ目は、全テナントのリソース・稼働状況・Universal Creditの消費を、一度のログインで横断的に見られるダッシュボード です。

画面上部で「サービス」（案件単位でまとめたコンパートメント）やプロファイル、リージョンを切り替えるだけで、リソース総数、稼働中のインスタンスやファンクション、データベース、ネットワークなどの状況をカテゴリ別に確認できます。配下のコンパートメントを含めて集計するかどうかも切り替えられます。

各サービスには担当者や説明、表示色を設定できるので、「今どの案件を見ているのか」が画面全体で直感的に分かるようにしてもらっています。

また、運用で地味に困る「秘密鍵・APIキー・パスワード・Walletはどこに保管したっけ問題」に対応するため、これらを暗号化して保管し、OCIリソースに紐付けて管理する「資材（鍵・認証情報）」機能も用意しました。有効期限も管理できるので、期限切れ間近の資材がダッシュボードで分かります。保管庫は「金庫」として明示的にロック・解錠する仕組みです。

高再現性なTerraform自動生成

ふたつ目のコア機能が Terraformの自動生成 です。ここが今回のツールで一番こだわっている部分です。

ポイントは、AIのテキスト生成に頼り切らない こと。リソースの構造や必須パラメータ、命名規則、出力先のワークスペースといった「確実に決まっている部分」はロジックとして実装し、その上で必要な箇所だけを柔軟に扱う設計にしています。（機能はまだ試行錯誤の段階です）

たとえばAutonomous Databaseの新規作成では、次のステップを画面上で進めます。

作成先のワークスペースを選ぶ
必要な値を入力する
plan の結果を確認してから apply する
完了

リソースはワークスペースの対象コンパートメントに作成され、生成されたtfファイルはそのままTerraformの管理下に入ります。（構想）ダッシュボードには「Terraform管理率」も表示されるので、手作業で作られたリソースがどれだけ残っているかも分かります。

3. 独自メソッド「FEARIDE」によるAIドリブン開発

本プロジェクトの開発には、自社独自のAIドリブン開発メソッド 「FEARIDE（フェアリーデ）」 を取り入れています。FEARIDEの詳細については、また別の機会に。

OCI Manager（仮）は、マルチテナント環境への認証・接続、多数のリソース種別の取得と集計、資材の暗号化管理、そしてTerraformの生成と plan / apply の実行まで、本来であればそれなりの人数と期間が必要な機能を含んでいます。

実はこのツールの開発を実際に担当しているのはインフラ担当者の1人だけです。それも通常業務の片手間で進めながら、FEARIDEに沿ってAIを相棒にすることで、短期間（期間としては2～3週間ですが、実質はもっと短い）で今の状態までたどり着きました。

4. 今後の展望と次回予告

社内ツールから、サービス展開へ

今はまず社内で構築と検証を繰り返しながら、機能と使い勝手を磨いている段階です。各テナントを一元管理できる分、セキュリティの脅威にもなりうるため、その辺りもしっかり考慮する必要があります。ただ、ゆくゆくは同じ課題を抱えている他社の方々に向けて、サービスとして外部展開していく こともできたらと考えています。

「テナントが多すぎて全体が見えない」「Terraformを書く余裕がない」「OCIに詳しい人が社内にいない」。こうした悩みは、私たちだけのものではないはずです。