APIをつないで、最初にぶつかった壁

APIキーを取得して .deploy.env に書いた。

接続テストを走らせた。

「つながった」と「使える」は、違う話だった。

---

準備：APIキーを2本登録した

otopublicのAIチームには、GeminiとCodex（OpenAI）が参加している。

これまでは両方とも手動で——別のウィンドウを開いて、質問を打ち込んで、返ってきた内容をコピーして渡す——という形で動かしていた。

「APIを登録すれば自動化できるのでは？」という話が出て、

まずAPIキーを取得して、プロジェクトの設定ファイルに追加した。

接続テストで、モデルの一覧が取得できた。

GeminiもOpenAIも、利用可能なモデルが数十〜百以上並んでいた。

「使える」という感触があった。この時点では。

---

実際に呼び出してみると

テスト用の質問を用意した。otopublicのep001〜ep002に登場するシーンに関連した、音楽的な内容だ。

最初のGemini呼び出しは、404エラーで返ってきた。

モデル名が正しくなかった。モデル一覧で確認できる名前と、generateContentエンドポイントで指定する名前の形式が微妙に違う場合があった。

モデル名を変えながら、いくつか試した。

gemini-3.5-flash で動いた。4秒ほどで返ってきた。

返ってきた内容は、「なぜ弦が『ぼよん』と鳴るのか」という質問に対して、

指の力不足・押さえる位置・隣の弦への接触——という3つの原因を1段落で整理したものだった。

ep001でヒロが「ぼよん」しか出なかった理由として、物語の中で描かれていた内容と一致していた。

これはリサーチツールとして機能する、という手応えがあった。

OpenAIの方は、クォータ超過のエラーが返ってきた。

課金設定を有効にする必要がある。接続はできているが、推論は走らない状態だ。

---

「つながる」と「使える」は違う

今回の実験で分かったのはそこだった。

APIキーを設定して接続テストが通ることと、

実際に質問を投げて答えが返ってくることは、別のステップだ。

モデル一覧の取得はAPIキーがあれば通る。

モデルの選択・エンドポイントの形式・課金の状態——それぞれが別の壁になる。

今回のGeminiは「モデル名を正しく指定する」という壁を越えたら動いた。

OpenAIは「課金設定」という壁がまだある。

壁の種類が違うだけで、どちらも「つながった」という段階から「使える」という段階への移行に、

それぞれ独自の手順が必要だった。

---

ここまでで分かったこと

APIの統合には、接続・認証・モデル選択・課金——という複数のレイヤーがある。

それぞれが独立して設定を要求する。

手動でやっていた作業をAPIで自動化すると、

その作業の「どこにコストがかかっているか」が明確になる。

今回はモデル名の指定と課金設定、という2つの具体的なコストが見えた。

Geminiは動いた。

返ってきたテキストは、otopublicのストーリーの文脈に合っていた。

次は、これをリサーチパイプラインの中に組み込む番だ。

---

この記事はotopublicの制作過程を記録した「裏側」記事です。

物語本文ではありません。具体的な未公開設定や、実在モデルが特定できる情報、

AIへの指示文そのものは、方針により伏せています。