APIキーの管理

コンソールのAPI & Webhooksでご自身のAPIキーを確認し、サーバー側で保管し、テスト用には別のサンドボックスアプリケーションを使用し、401エラーと403エラーを解消する方法です。

執筆: Didit サポート · 更新日: 2026年8月19日

APIキーは、コンソールのサイドバーのAPI & Webhooksにあり、作業中のアプリケーションに紐づいています。パスワードと同様に扱ってください。そのアプリケーションの権限でAPIへの完全なアクセスを許可するものです。

#キーの見つけ方

1. ビジネスコンソールにログイン

   business.didit.meにアクセスしてサインインします。

2. アプリケーションを選択

   コンソール上部のドロップダウンから、対象のアプリケーションを選びます。アプリケーションごとに独自のキーがあります。

3. API & Webhooksを開く

   ここにAPIキーがあり、webhookの送信先とその署名シークレットも一緒に確認できます。

1234

1. Create API keyで新しいキーを発行します。キーはアプリケーションごとです。
2. シークレットはここに一度だけ表示されます。自社のシークレット管理システムにコピーしてください。
3. Rotate secretは、キーの名前を変えずにシークレットだけを差し替えます。
4. Last usedを見れば、失効させる前に、そのキーが使われているものか忘れられたものかを判別できます。

#APIキーと署名シークレットは別物

混同すると分かりにくいエラーが発生するため、明確にしておく価値があります。

署名シークレットをAPIキーとして送信すると401になります。APIキーでwebhookを検証しようとすると署名が一致しません。どちらもよくある間違いです。

#テスト用のキーを取得する

本番環境に対してテストを行うことはありません。サンドボックスモードで別のアプリケーションを作成してください。サンドボックスのセッションは外部チェックをすべてモックし、課金されることも実際のユーザーデータに触れることもありません。構築中はそのキーを使い、実際の検証には別の本番アプリケーションを維持してください。

本番アプリケーションに「テスト用キー」というものは存在しません。キー自体が環境なので、シークレットを保管する場所でキーの名前を明確に区別しておく価値があります。サンドボックスでのテストをご覧ください。

#キーのローテーション

キーが漏洩した可能性がある場合は、同じAPI & Webhooksページから再生成してください。再生成すると古いキーは即座に無効になるため、ボタンを押した瞬間に本番トラフィックが失敗し始めないよう、先に使用箇所すべてを更新してください。

定期的なローテーションは良い習慣です。単なるクリックではなく、デプロイとして計画してください。

#401と403の解消

特定のワークフローに対する403は、ほとんどの場合、そのキーがそのワークフローを所有しているアプリケーションとは別のアプリケーションのものであることを意味します。コンソールでアプリケーションを切り替え、そちらのキーをコピーしてください。詳細はAPIエラーとその意味をご覧ください。

#キーでできることを制限する

キーがアクセスできるデータの種類を制限したい場合（例えば、あるサービスに書類の画像を取得させたくない場合など）、それはキーの設定ではなく権限の問題であり、利用できる内容はアカウントによって異なります。キーに制限がない、あるいは制限があると思い込むのはどちらも危険なので、サポートに確認してください。

#チーム内で誰がキーを見られるか

キーの表示はロールに従います。DeveloperロールはAPIキーを含みますが、Readerは含みません。チームメンバーがこのページを見つけられない場合は、報告の前にまずロールを確認してください。チームメンバーの招待とロールの設定をご覧ください。

#すべての呼び出しが記録される

APIキーによるリクエストは、人物ではなくアプリケーションに紐づけてAudit Logsに記録されます。だからこそ、複数のサービスで1つのキーを共有していると、インシデント発生時の調査が難しくなります。利用者ごとに1つのキーを持たせるほうが、状況を把握しやすくなります。監査ログの利用をご覧ください。