環境を説明するたった一つの文章から、ゲームエンジン内で歩き回り、ジャンプができる、ゼルダの雰囲気を纏ったバイオルミネセンス（生物発光）の峡谷を探索するリギング済み3Dキャラクターが完成しました。モデリングソフトを開くことも、低レベルなレンダリングコードを一行も書くこともありませんでした。
この記事では、途中で犯した失敗を含め、プロセス全体を解説します。私が使用したAI機能はすべて同一プラットフォームであるAtlas Cloudのものであり、ワークフロー全体が一つのAPIキーで完結しました。
短縮版：かつてはチームが必要だったことが、今や一つのAPIで完結
かつて、プレイ可能な3Dゲームを作るには、いくつかの技術的なハードルをクリアしなければなりませんでした。ZBrushやBlenderでのモデリング、キャラクターのスケルトンリギング、キーフレームやモーションキャプチャによるアニメーション、そしてそれらのアセットをゲームエンジンに読み込むためのコーディング知識が必要です。ほとんどの初心者にとって、これらのステップの一つだけでもプロジェクトを断念するには十分な理由となりました。
私が試したかったことは単純です。AIは今やこれらのステップを端から端までつなぎ、モデリングやプログラミングの経験が全くない人でも、実際にエンジン上で動作する3Dゲームデモを作成できるのか、ということです。
試してみた結果、答えは「イエス」でした。画像生成から3D変換、テクスチャリング、スカイボックス作成に至るまで、AIパイプライン全体が単一のAPIキーで動作しました。BlenderでのアセンブリやGodotプロジェクトのセットアップといったエンジニアリング作業は、Claudeが主導しました。私の役割は、結果を検証し、次に何をしたいかを指示することでした。
一つのAPIキーですべてのワークフローをカバー。 GPT Image 2、YouChuan MJ V8.1、Nano Banana 2、Seed 3D、Hunyuan 3Dなどのモデルはすべて、同一のAtlas Cloud APIキーを通じて実行されました。複数のプラットフォームに登録したり、別々のアカウントに残高をチャージしたり、手作業で異なるAPIを統合したりする必要はありませんでした。
ワークフローの全体像（実行順）
plaintext1① GPT Image 2 → 環境コンセプトアート：ゼルダ風のレンダリングと暗い生物発光の峡谷 2② GPT Image 2 edit → 環境を「3Dジオラマ」用に調整し、アイソメトリックなベース画像にクリーンアップ 3③ Hunyuan 3D → ジオラマ全体を一度の処理で3D化し、シーン全体をストレステスト 4④ GPT Image 2 → 星空の背景として使用する360°スカイボックスを同じモデルで生成 5⑤ YouChuan MJ V8.1 → レンジャーキャラクターのコンセプトをデザインし、主人公の魂を定義 6⑥ Nano Banana 2 → キャラクターの一貫性を維持しつつ、正面向きのTポーズのリファレンスへリドロー 7⑦ Seed 3D → キャラクター画像を3D化：綺麗な髪と指のジオメトリ、リギング対応構造、PBRとByteDanceのSeedモデルを内蔵 8⑧ Nano Banana 2 + Hunyuan 3D → ランタン（小道具）を個別に作成 9⑨ Mixamo + Blender × Claude → Mixamoで自動リギングと歩行/走行/ジャンプアニメーションを作成。Claude(MCP)がBlender内でのインポート、マテリアル接続、位置合わせ、GLBエクスポートを処理 10⑩ Godot 4 → 統合：キャラクターコントローラー、三人称カメラ、スカイボックス、ボリュームフォグ、光るランタンの実装
①から⑧までのステップはすべて「One API for All Media AI」を掲げるAtlas Cloud上のAI機能を使用しており、300以上のモデルを単一インターフェースから呼び出せます。これにはステップ⑤のYouChuan MJも含まれます。ステップ⑨のMixamo、ステップ⑩のGodot、およびバックエンドのBlenderはすべて無料のサードパーティツールです。
以下に、各ステップで使用したプロンプトを含めた実践プロセスを記します。
ステップ1 | GPT Image 2：世界を描く
出発点はキャラクターではなく、世界観の美学でした。Atlas Cloud上のGPT Image 2を使用して環境コンセプト画像を生成し、ゼルダ風のレンダリングと暗いバイオルミネセンス峡谷というトーンを決定しました。
環境用プロンプト ('text-to-image'; Playgroundパラメータでアスペクト比を '16:9' に設定):
plaintext1bioluminescent fantasy canyon at night, stylized painterly game concept art, towering deep-indigo and magenta rock cliffs glowing with teal veins, tall bell-shaped glowing flora with crystal tips, ancient carved standing stones with angular constellation glyphs, winding ridge path, a small hooded ranger with a warm lantern beside a campfire for scale, misty atmospheric depth, starry night sky, cool teal-and-violet palette with warm amber accent, dreamy magical mood, soft cel-shaded painterly rendering, cinematic wide establishing shot, high detail
この画像がプロジェクト全体の美的基準となりました。カラーパレット、ライティング、世界観はこの段階で決定されました。この時点での唯一の問いは、見た目が優れているかどうかであり、モデリングが可能かどうかは後回しでした。
なぜ環境作成にGPT Image 2を選んだのか： 「環境シーンと後のジオラマ変換」パイプラインにおいて、テストの結果GPT Image 2が最も安定していました。構図が明瞭で色の再現性も高いからです。ジオラマ変換のために他の画像モデルを試すと、しばしば色や質感が失われ、白い粘土のようなモデルになってしまうことがありました。そのため、環境作成にはGPT Image 2を固定で採用しました。
ステップ2 | GPT Image 2 'edit'：3Dジオラマへの変換
次に、コンセプト画像を3Dモデルとして認識できるものに変換する必要がありました。広角のコンセプト画は直接モデリングの入力としては不向きで、ライティングがドラマチックすぎ、背景が複雑すぎるためです。そこでGPT Image 2の edit 機能を使用し、アイソメトリックなジオラマ風のベース画像に整理することで、次のステージのための素材を準備しました。
ジオラマ変換プロンプト (GPT Image 2 'edit', ステップ1の環境画像を元画像として使用):
plaintext1Convert this scene into a clean 3D-renderable isometric diorama, keeping ALL original colors and textures fully intact — purple-magenta rock, teal glowing bell flowers, carved runestones, mossy ground. Plain simple background. Even soft neutral lighting so the true surface colors read clearly; remove only the heavy colored rim-light, fog and warm campfire glow. Do NOT desaturate, do NOT turn into grey clay. Preserve material and texture detail, single connected terrain chunk, 3/4 orthographic view, no text, no characters.
最大の罠：グレーや白の粘土モデルにさせないこと。 Hunyuanは次のステージで、元画像の「色」からテクスチャ情報を直接読み取ります。グレーの粘土のような画像を与えると、グレーのモデルしか返ってきません。だからこそプロンプトで「ALL original colors（元の色をすべて維持）」や「Do NOT desaturate（彩度を落とさない）」と明記しています。目的は、強いリムライトや霧、キャンプファイヤーの光を取り除き、ベースカラーと質感を保つことです。
ステップ3 | Hunyuan 3D：ジオラマ全体を一度に3D化
このステップは意図的なストレステストでした。シーンを個々のアセットに分解するのではなく、前段のジオラマ画像全体をHunyuan 3Dに入力し、一度に再現できるかを確認しました。
結果は予想以上に実用的でした。ジオラマは約10万ポリゴン（面数）で生成されました。全体的な構造、岩の形状、地形の関連性は良好に保持されており、単なる白いメッシュではなくPBRテクスチャ付きでした。もっと平坦なレリーフになるかと予想していましたが、ジオラマ用の前処理を経ることで、シーン全体が十分に活用可能なモデルとして出力されたのは嬉しい驚きでした。
背後にある原理： ここではHunyuan 3Dの単一画像生成（Image-to-3D）機能を使用しました。フルワイドの画像を与えると、画像と様式的な推論に基づいて不足している3次元構造を補完します。最も印象的なのは、正面からの広角画像一枚からでも、裏側や底面を同じスタイルで推論し、平らなレリーフではなく完全な3Dシーンを作り出したことです。ジオラマとしては十分な能力です。より洗練された環境が必要な場合は、シーンをパーツごとに分け、個別にモデリングしてエンジン内で組み立てるのが正攻法です。
なぜ環境にSeed 3DではなくHunyuanを選んだのか： 同じジオラマ画像で両モデルを試した結果、環境に関してはHunyuanの方がテクスチャが豊かでソリッドでした。岩の模様や地面のディテールがしっかりと反映されました。Seedの環境生成はテクスチャが欠落しがちで、全体的に粗い仕上がりでした。そのため環境シーンにはHunyuanを採用しました。キャラクターに関しては結論が逆になります（ステップ7で解説）。
プロジェクト全体を通しての鉄則：面数（ポリゴン数）を10万以下に抑える。 ゲームでは、過剰なディテールよりもスムーズに動作するモデルの方が重要です。面数が多すぎるとリギングが困難になり、エンジンの負荷が増え、反復作業に時間がかかります。プレイ可能なゲームアセットであれば、5万〜10万ポリゴンで十分です。モデリングソフトが提供する50万〜100万ポリゴンは、映画や3Dプリント向きであり、プレイ可能なデモには不要です。
ステップ4 | GPT Image 2：360°スカイボックス生成
ゲーム内の星空はモデリングしていません。エンジン内でスカイボックス（世界を包み込むパノラマ画像）として設定しました。ここでもGPT Image 2を使い、二段階で作成しました。
- ステップ1の環境コンセプトを画像間変換（Image-to-image）の参照として使用し、地形を除外した綺麗な星空を生成しました。色と雰囲気は元々の設定を維持しています。
- その後、
edit機能を使用して、左端と右端がシームレスに繋がる2:1比率の正距円筒図法パノラマへ変換し、エンジンに読み込める状態にしました。
スカイボックス用プロンプト (image-to-image, ステップ1の環境画像を元画像として使用; アスペクト比 '2:1'):
plaintext1A pure night sky only, no terrain and no horizon line, bioluminescent dark fantasy game sky: smooth deep indigo-to-royal-blue gradient, a dense field of bright white and pale-cyan stars, soft flowing teal-green aurora ribbons, a faint cyan-and-magenta nebula glow, one or two thin meteor streaks, dreamy magical atmosphere, soft cel-shaded painterly rendering, no ground, no mountains, no characters, sky fills the entire frame.
360°パノラマへの変換 ('edit', 上記の空画像を使用; アスペクト比 '2:1'):
plaintext1Convert this night sky into a full 360-degree equirectangular spherical panorama with a 2:1 aspect ratio, for use as a seamless game skybox. Wrap horizontally so the left and right edges line up with no visible seam. Keep the same teal-and-violet palette, bright stars and soft aurora. No ground, no characters, seamless tiling.
このステップでも、一つのキーで全工程をカバーできる利点が現れています。環境画像、ジオラマベース、スカイボックスまで全てGPT Image 2で完結しました。
ステップ5 | YouChuan MJ V8.1：レンジャー主人公のデザイン
環境が決まったら主人公の番です。キャラクターはプロジェクトの魂です。スタイルの一貫性と視覚的な雰囲気がプロジェクトに最適だったため、Atlas CloudのYouChuan MJ V8.1を選びました。
青い髪の女性レンジャーで、ポニーテール、光るティール（青緑）のルーン装飾が施されたレザーベスト、スリムな長袖のインナー、指なし手袋、体にフィットしたパンツ、丈夫なブーツという構成をイメージしました。
キャラクタープロンプト (記述のみ。アスペクト比とスタイルの強さはパラメータパネルで設定):
plaintext1full body character design of a young female explorer-ranger, athletic slim build, short tousled hair or a low tied-back ponytail (no long loose hair over the shoulders), wearing a fitted sleeveless leather tunic with glowing teal-rune trim over a slim close-fitting long-sleeve underlayer, fitted trousers tucked into sturdy boots, fingerless gloves and forearm bracers, a small warm-amber lantern clipped at the hip, gentle determined expression, bioluminescent dark fantasy style, cool teal-and-violet palette with warm amber accent glow, soft cel-shaded painterly rendering, calm neutral standing pose with arms held clearly away from the torso, clean plain background, full body visible head to toe, clearly separated arms and legs, NO cape, NO robe, NO flared sleeves, NO face-covering hood, game character concept art, high detail
パラメータ設定： 全身を収めるためアスペクト比を '2:3'、スタイル 'raw'、スタイライズ '250' に設定。
プロジェクト最大の教訓：リギングに適したキャラクターを選ぶこと。
最初のバージョンはフードをかぶった巫女風で、広い袖と長いローブ、フードで顔が隠れ、髪が肩に垂れていました。見た目は美しいですが、リギングは完全に破綻しました。ローブは両足を一つのスカート状の円錐体にしてしまい、自動リギングが足を認識できません。広がった袖は骨で制御できない巨大な布の塊となり、キャラクターが動くたびに突き抜け（クリッピング）が発生しました。
根本的な問題は、浮いている布の表現は本来「布シミュレーション」が担うべきであり、それを硬いスケルトンに強制的に当てはめるのには限界があるということです。特に初心者には厳しいです。
だからこそ、 limbs（四肢）が明確に分かれ、体にフィットした服を選ぶのが正解です。プロンプトで繰り返した
fitted、NO flared sleeves、clearly separated arms and legs、NO hoodは偶然ではありません。失敗要因を排除するための防波堤です。適切なキャラ選びは、後のリギング作業の苦労を半分に減らしてくれます。
ステップ6 | Nano Banana 2：一貫性を保ったTポーズへの書き直し
MJの画像は美しいですが、ポーズや視点が不規則なイラストであり、直接モデリングには使えません。3Dモデリングとリギングには、両腕を水平に広げ、四肢が離れ、左右対称な「Tポーズ」のリファレンスが最適です。これによりAIが3D化する際の精度が最大化されます。
ここでNano Banana 2を使用しました。キャラクターの個性を維持しながら、Tポーズへクリーンに書き直します。また、ランタンは後ほど個別にモデリングするため手から外し、腰布が足に絡まないよう短くフラットに修正しました。
Tポーズ処理用プロンプト (NB2 'edit', ステップ5のMJ画像を元画像として使用):
plaintext1Redraw this exact character in a clean front-facing T-pose for 3D modeling: both arms extended straight out horizontally to the sides with a clear visible gap between the arms and the torso, hands open and empty, legs straight and clearly apart (not touching), standing upright, symmetric, facing forward. Keep the identical character identity — blue tousled short hair with a small ponytail, same face, sleeveless vest with glowing teal-rune trim, fitted long-sleeve underlayer, fingerless gloves, fitted trousers, chunky boots, cool teal-and-violet palette with warm accents. Remove the lantern and any held prop. Replace the bulky side hip pouch with a slim flat tactical belt. Shorten the hanging front cloth flap so it ends above mid-thigh, never between the legs. Even neutral lighting, plain pure white background, no shadows, full body head to toe, clearly separated arms and legs, everything fitted close to the body, NO cape, NO robe, NO flared sleeves, NO hood, clean game-character reference.
Nano Banana 2を選んだ理由は、キャラクターの一貫性を保つ能力に長けているためです。ポーズ変更や視点変化でも顔や服の雰囲気が崩れません。高速かつ低コストで、繰り返し検証するのに最適でした。
このステップは全パイプラインの「翻訳者」です。人間が見て良いと思う画像を、3Dモデルが読める画像へ変換する作業です。
なぜAポーズではなくTポーズか？ 腕を水平に広げることで、脇の下と胴体の重なり（オクルージョン）が最小限になり、3D変換時に幾何学的なクリーンさと自動リガーによる高い認識率が得られるためです。
もう一つ：画像生成モデルに入力する前には、徹底的にクリーンにしてください。背景を真っ白にし、キャラを中央に配置し、全身を収め、複数のキャラクターを混ぜないこと。ステップ7のSeed 3Dは、この画像のクオリティに依存します。
ステップ7 | Seed 3D：一枚の正面画像から完全なテクスチャ付きモデルへ
これがハイライトです。キャラクターにはAtlas Cloud上のByteDanceのモデル「Seed 3D」を使用しました。前のステップのTポーズ正面画像を入力すると、PBRテクスチャ付きの完全なモデルが生成されました。形状とマテリアルが一度に完成します。同一のAPIキーが画像生成から3D生成までシームレスにつなぎました。
なぜ環境にはHunyuan、キャラにはSeedなのか？ 両モデルを同じ素材でテストした結果、用途を分けるのが最善という結論に至りました。
| 用途 | モデル | 理由 |
|---|---|---|
| キャラクター | Seed 3D | 髪や顔の重なりをよりクリーンに分離でき、手袋や指の形状とテクスチャが良好で、リギングに向いているため。テクスチャが遠目にはやや粗いのが難点だが、形状の優位性が勝る。 |
| 環境 | Hunyuan 3D | ステップ3で見た通り、岩の模様や地面のディテールにおいて、より豊かでソリッドなテクスチャを生成するため。 |
テクスチャよりもジオメトリを優先する理由： キャラクターは後でリギングされ、アニメーションする必要があります。髪と顔が適切に分離されているか、指がきれいかといったトポロジー（形状構成）がリギングの成否を分けます。これは後から修正が困難な欠陥です。一方でテクスチャの粗さは、エンジンのライティングで調整可能であり、後から焼き直すこともできます。キャラクターに関しては、Seedの形状的優位性が重要でした。
実運用において、Seed 3Dは良好でした。正面一枚の画像から、同じスタイルの後頭部、背中、足の裏を合理的に推論しました。PBRマテリアルが含まれ、髪や指もきれいでした。まさに、リギング済みキャラとして使える理由です。
Seedパネルの設定：
Subdivision Levelには3段階あります。lowは10万ポリゴン、mediumは50万、highは100万です。面数制限のルールに従い、今回はlowを使用しました。ファイル形式には、BlenderとGodotの両方で標準認識されるPBRテクスチャ付きのGLBを選択しました。
ステップ8 | Nano Banana 2 + Hunyuan 3D：ランタン小道具の作成
ランタンをキャラクターモデルに溶接せず、別のアセットとして作成しました。これによりリギングとアニメーションをクリーンに保てます。エンジン内ではキャラクターの手にアタッチするだけです。
まずNano Banana 2で、3/4ビューのクリーンなランタン画像を生成しました。光はエンジン内で処理するため、発光をテクスチャに焼き付けないよう指示しました。
ランタン用プロンプト (NB2 'text-to-image'):
plaintext1A single rugged adventurer's handheld lantern as a standalone 3D game asset, compact portable explorer design, weathered dark gunmetal-and-brass frame with glowing teal-rune engravings, a warm-amber glowing crystal core behind simple flat glass panels, ONE single sturdy fixed carry ring on top only — no side handle, no swinging bail, a few practical leather straps and rivets, bioluminescent dark fantasy style matching a teal-and-violet explorer with warm amber accents, centered on a pure white background, even neutral studio lighting, full object visible, 3/4 orthographic view, true material colors, no strong glow baked in, no shadows, clean reference.
次にHunyuan 3D Proに入力（面数4万、PBR有効、GLB形式）。金属フレームとルーンの装飾がうまく維持されました。
なぜ小道具にSeedではなくHunyuanを選んだのか： Hunyuan Proは面数を4万まで下げられます。Seedの最小は10万です。小さな小道具であれば、4万ポリゴンの方がエンジンにとって軽量です。
ステップ9 | Mixamo：無料リギングとアニメーション
この段階でモデルはまだ置物です。動きをつけるにはスケルトンとアニメーションが必要で、Adobeの無料ツールMixamoのWeb版を使用しました。Adobe IDがあればコードを書かずに使えます。
リギングとアニメーションの両方がMixamo内で完結するため、複雑なリターゲティングやプラグイン、Blenderの苦痛なワークフローが不要です。 これがMixamoを選んだ最大の理由です。初心者はモデルをアップロードして数回クリックするだけで、歩いたりジャンプしたりできるキャラをダウンロードできます。
- リギング：モデルをアップし、顎、手首、肘、膝、股間にマーカーを置く。Mixamoが自動で標準的な人間スケルトンを生成。このレンジャーは服が体にフィットし四肢が分かれていたため、一発で成功しました。
- アニメーション：ライブラリで「Walking」「Running」「Jumping」を検索し、適用してプレビュー。
- ダウンロード：各アニメーションで
FBX Binaryを選び、モデルを含むWith Skinにチェック、そしてIn Placeをチェック（その場で動くため、移動はエンジン側のコードで制御）。
失敗談1：FBXアップロード時に「既存スケルトンをマッピング不可」エラーが発生。 最初、ClaudeでBlender操作してFBXをエクスポートしたところ、Mixamoがモデル内のスケルトンを誤認識しました。Claudeの解決策はOBJ形式でのエクスポートでした。OBJには骨の概念がないため、Mixamoが自動リギングを強制実行せざるを得なくなり、問題が回避されました。テクスチャはリギングに関係ないためOBJで十分でした。
失敗談2：Mixamoはスケール0.01でダウンロードされる。 エンジン読み込み時にキャラが極小になります。Claudeがこれを検知し、オブジェクトスケールを1.0（身長約1.5m）へ自動修正しました。
舞台裏の真実： Mixamoがリギングとアニメーションを担い、Blender内でのクリーンアップ作業はClaudeがMCP（Model Context Protocol）経由で行いました。MCPはLLMが直接PC上のソフトウェアを操作する架け橋のようなものです。FBXのインポート、サイズの復元、メッシュとスケルトンの位置合わせ、テクスチャの再接続などをClaudeが処理し、ゲームエンジン用GLBとしてエクスポートしました。
ステップ10 | Godot 4：エンジンへの統合と実行
最終ステップはGodot 4です。無料かつオープンソース、インストールは100MB程度で登録不要、GLBをネイティブサポートしています。ここですべての雰囲気が統合されました。Unityに慣れているならUnityでも良いですが、Godotは軽量で習得が早いです。プロジェクトファイルがテキストベースなため、Claudeが直接コードを書いたり修正したりするのに向いていました。
Claudeは3つのGLB（キャラ、環境、ランタン）をプロジェクトに取り込み、以下を設定しました：
- キャラクターコントローラー：
CharacterBody3Dと数十行のGDScriptで、WASD移動、Shift走行、ジャンプ、マウス視点、三人称カメラを実装。 - アニメーションステートマシン：Mixamoアニメをif文で切り替え。
- スカイボックス：
WorldEnvironmentとPanoramaSkyMaterialで、ステップ4の360°パノラマを接続。 - ボリュームフォグとグロー：Godot 4の標準機能と花の emissive（発光）設定で魔法のような峡谷を演出。
- ランタンのライティング：手のアタッチポイントに
OmniLight3Dを配置。歩くたびに温かい光が地面を照らし、探索感を演出。
Godotプロジェクト自体もClaudeが書きました。私がやりたいことを説明し、Claudeがプロジェクト内で直接書き、修正し、実行検証を繰り返しました。低レベルなコードを書かなかったといってもコードが存在しないわけではありません。Claudeが技術的な負担を背負ってくれたのです。
なぜAtlas Cloudを使ったのか
このワークフローの難しさは、ツール一つ一つを学ぶことではなく、登録や課金、API統合が必要な多数のプラットフォームを行き来することにあります。Atlas Cloudはそれを簡素化しました：
- 一つのAPIキーで全てが完結。 これが最も重要でした。環境生成、キャラ生成、変換、モデリングまで全て同一キーで動作しました。
- One API for All Media AI。 300以上のモデルを一つのインターフェースから呼び出せます。
- 新たに3Dカテゴリーを追加。 Seed 3DやHunyuan 3Dが統合されており、PBRテクスチャ付きのImage-to-3Dが一撃で完成します。
- フロンティアLLMも同キーで利用可能。 ClaudeのようなLLMから画像、3Dまで同じキーなのが、一人でのワークフローを可能にしました。
- 競争力のある価格設定。 低コストで繰り返し試行錯誤できました。
- MCP、CLI、Skills。 API以上の機能が充実しています。
一言で言えば、かつてはチームと多数の契約が必要だったことが、今や一人で、一つのAPIキーで、一文から3Dワールドを完成させられるのです。
今すぐ試す
Atlas Cloudを開き、新しい3Dカテゴリーへ向かってください。まずは最初のキャラクター生成から。モデリングやプログラミングの知識は不要です。AIがモデリングを担い、エンジンが命を吹き込みます。あなたの仕事は、世界を想像することだけです。
この記事で使用した全てのモデル（GPT Image 2, YouChuan MJ V8.1, Nano Banana 2, Seed 3D, Hunyuan 3D, Claude）は、同一のモデルプールで利用可能です。
Atlas Cloudで両モデルを使うには？
Atlas Cloudでは、プレイグラウンドで試してから、単一API経由で利用できます。
方法1：Atlas Cloud プレイグラウンドで直接利用
https://www.atlascloud.ai にアクセスして利用してください。
方法2：API経由で利用
ステップ1：APIキーを取得
コンソールでAPIキーを作成します。
ステップ2：APIドキュメントを確認
APIドキュメントでエンドポイントやパラメータを確認してください。
