既存のデータベースに Directus を接続して管理画面と API を即座に生成する

エンジニアの採用が難しかったり、外注費用の負担が大きかったりする初期のスタートアップにとって、バックエンドの構築は巨大な障壁です。Directus は、既存の SQL データベースをそのままに、その上に管理者 UI と API レイヤーを即座に構築できるツールです。コードを一行も書かずに運用データを安全に管理し、外部サービスと連携する環境を作るための具体的な設計方法をまとめました。

元データを保護するフィールド制御と権限設定

Directus はデータベースのスキーマをリアルタイムで読み取りますが、元の構造を強制的に変更することはありません。運用中の DB の整合性を維持しながら管理の利便性を高めるには、実際のテーブルには存在しないが UI 上でのみ動作する「仮想フィールド」を活用する必要があります。例えば、複数のテーブルが絡み合う複雑な関係を、UI 上では単純なドロップダウンメニューとして表示させることができます。

データ流出を防ぐには、ロールベースのアクセス制御（RBAC）をカラム単位で細かく設定する必要があります。顧客のパスワードハッシュや内部の精算ロジックのような値は、管理者画面であっても特定の権限がなければ非表示にします。登録日や決済金額のように、一度記録されたら変更すべきでないデータは「読み取り専用」にロックし、ミスによるデータの改ざんを防ぎます。

ビジネスルールに基づいた条件付きの権限設定も可能です。

• ロール設定メニューから特定のカラムの権限ポリシーを選択します。
• 条件タブで「注文ステータスが配送中の場合」というルールを入力します。
• この条件に一致する場合、価格カラムの編集権限を剥奪するように設定します。

このように設定すれば、カスタマーサポートや運用スタッフが誤って配送済みの商品の価格を書き換えてしまう事故を未然に防ぐことができます。

コードなしで実装するビジネスロジックと自動化

単純なデータの入出力にとどまらず、特定の条件でのみ動作するロジックは「Flows」機能を利用して視覚的に設計します。フォレスター・コンサルティングの 2022 年の調査によると、このようなローコード自動化の導入により、運用コストを最大で約 30% 削減できるといいます。サーバーレス関数を別途作成しなくても、直感的なノードの連結だけでトランザクションの安定性を確保できます。

在庫がない場合に注文の入力をブロックするロジックは、データが DB に書き込まれる直前に作動する「フィルタートリガー」を使用します。スクリプトノードで現在の在庫を確認し、不足している場合にエラーを発生させれば、プロセス全体がキャンセルされ、不正なデータが残ることはありません。

自動化フローの構成手順は以下の通りです。

• Flows メニューで新しいフローを作成し、トリガーを Filter (Blocking) に設定します。
• 条件ノードを追加し、顧客ランクや決済ステータスごとに分岐点を作ります。
• スクリプトノードを連結し、JavaScript で複雑な割引率の計算や在庫検証ロジックを記述します。

外部サービス API 連携とセキュリティ管理

Directus は、通知サービスや決済モジュールなどの外部サービスとデータをやり取りするハブになります。セキュリティのため、API キーはソースコードに含めず、Directus の環境変数に登録して管理します。これにより、開発用キーと本番用キーを誤って混ぜてしまう事故を防げます。

決済完了の信号を受け取るウェブフックを設定する際は、セキュリティ検証が肝心です。Toss Payments や Stripe から送られてくる秘密のヘッダー値を照合しなければ、誰かが偽の決済信号を送って注文を成功させてしまう可能性があります。また、非同期設定を有効にして、外部サービスには即座に応答を返し、内部ロジックはバックグラウンドで処理することで、システムの負荷を軽減します。

決済連携システムの構築方法です。

• ウェブフックトリガーを作成してエンドポイントを公開し、非同期オプションを有効にします。
• 条件ノードで、外部サービスが送信した秘密のヘッダーが自分の環境変数と一致するか確認します。
• アイテム更新ノードを連結し、外部から渡された注文 ID を自社 DB の注文ステータスカラムに反映させます。

トラフィック増加に備えたキャッシュとパフォーマンス最適化

ユーザーが増えて API のレスポンスが遅くなった場合は、インフラ設定を調整する必要があります。Directus は内部に強力なキャッシュメカニズムを備えています。頻繁に変更されないお知らせや商品カテゴリーは、キャッシュの有効時間を 1 時間程度に設定するだけで、レスポンス速度をミリ秒単位まで短縮できます。

クエリ速度を決定するのは、結局のところインデックスです。Directus v11 からは、管理者画面から直接 DB インデックスを追加できるようになりました。検索やソートによく使われるカラムにインデックスを貼るだけで、DB の負荷を大幅に抑えられます。

パフォーマンス最適化の実行ステップです。

• 環境変数ファイルでキャッシュを有効化し、照会リクエストが多いデータに有効時間を付与します。
• データモデル設定で、フィルタリングが頻繁なカラムにインデックスを作成します。
• 読み取り専用レプリカ DB を接続し、照会リクエストのみを分散処理するように設定します。

障害復旧のための自動バックアップとログ追跡

運用中に発生した問題はログを通じて追跡します。Directus はすべてのデータ変更履歴を記録するため、「いつ」「誰が」「どの値」を変更したかを一目で把握できます。ただし、ログが溜まりすぎると DB の容量を圧迫するため、ビジネス上のポリシーに合わせて保存期間を設定するのが望ましいです。

システム全体が停止する状況に備え、自動バックアップ体制も整えるべきです。Docker Compose の設定にバックアップ専用のコンテナを追加し、毎日深夜に DB スナップショットを外部のクラウドストレージに転送します。

自動バックアップの構築方法です。

• Docker Compose ファイルにバックアップイメージのサービスを追加します。
• クロン（cron）式を使用して、毎日午前 2 時などトラフィックの少ない時間に実行されるよう予約します。
• AWS S3 バケット情報とアクセスキーを連携し、バックアップファイルを外部ストレージに隔離して保存します。

この構造を整えておけば、ハードウェアの障害や誤操作でデータを削除してしまっても、1 時間以内にシステムを復旧し、ビジネスを再開できます。運用の設計に力を注ぐことで、創業者はコードと格闘する代わりに、顧客価値に集中する時間を稼ぐことができるのです。