AIとAPIを使ったアプリ開発の進め方|コード生成・機能連携・自動化の違い
「AIにコードを書いてもらいたい」「アプリに文章を生成する機能を付けたい」。どちらもAIを使った開発ですが、AIを利用する場面と、必要な仕組みは異なります。
開発中にAIでコードを作ること、完成したアプリからAIのAPIを呼び出すこと、テストや公開作業を自動化することは、分けて考えると整理しやすくなります。すべてを一度に導入する必要はなく、作りたい機能に合わせて組み合わせます。
この記事では、学習用のクイズアプリを例に、AIとAPIを開発へ取り入れる手順を解説します。コードの生成だけでなく、動作確認、外部サービスとの連携、公開後の費用や保守まで見通せるようにしましょう。
目次
1.AIとAPIは、開発のどこで使うのか
APIは、プログラムから別のソフトウェアの機能やデータを利用するための窓口です。AIの文章生成に限らず、地図の表示や外部サービスからの情報取得などにも使われます。
一方、開発を支援するAIは、コードや説明、修正案などを生成します。AIに手伝ってもらって作ったアプリが、実行時にもAIのAPIを必要とするとは限りません。
| 使い方 | 具体例 | 確認すること |
|---|---|---|
| 開発中にAIを使う | 画面のコード、修正案、テストの案を生成する | 仕様との一致、実行結果、変更による影響 |
| アプリからAIのAPIを使う | 入力された文章の要約や解説の下書きを生成する | 回答内容、応答時間、送信データ、利用料金 |
| AI以外のAPIを使う | 外部サービスのデータを取得・更新する | 認証、権限、データ形式、利用条件 |
| 開発作業を自動化する | コード変更時にテストやビルドを実行する | 実行条件、確認項目、失敗したときの扱い |
たとえば、登録済みの問題と解説を表示するクイズアプリなら、AIにコード作成を手伝ってもらいながら、完成したアプリはAIのAPIを使わずに動かせます。利用者の質問に応じて新しい説明を生成したい場合に、APIを使う構成を検討します。
2.最初に「何を作り、何を確認するか」を決める
AIへ依頼する前に、利用者の操作と期待する結果を整理しましょう。「便利な学習アプリを作って」だけでは、問題形式や回答後の動作をAIが推測することになります。
最初の試作では、1問を表示して、回答後に正誤と解説を出すところまでに絞ります。次の表は、学習用の仕様例です。
| 項目 | 今回の仕様例 |
|---|---|
| 問題 | 内容を確認済みの問題を1問用意する |
| 回答 | 3つの選択肢から1つ選ぶ |
| 判定 | 登録済みの正解と、選んだ選択肢を比較する |
| 表示 | 正解・不正解と、登録済みの解説を表示する |
| 回答後 | 同じ問題に再回答できないようにする |
| 初期状態への戻り方 | ページを再読み込みする |
この段階では、ログイン、成績保存、ランキングなどを追加しなくても、基本動作を確認できます。機能を増やすときは、元の動作が保たれているかを確かめながら進めましょう。
3.AIでコードを生成し、小さな単位で動作を確認する
依頼には構成・動作・確認事項を含める
AIにコードを依頼するときは、使う言語やファイル構成、必要な動作を具体的に伝えます。既存のアプリを修正する場合は、関連するコードと、変更してよい範囲も共有してください。
次の文章は、最初の試作に使う依頼例です。問題文や正解は、自分で内容を確認したものに置き換えて使います。
学習用のクイズアプリを作ります。今回は、1問を表示して回答を判定するところまで実装してください。
【構成】
HTML・CSS・JavaScriptを使い、index.html、style.css、script.jsに分けます。外部ライブラリ、外部API、データベースは使わず、index.htmlをブラウザで直接開いて動作する構成にしてください。
【動作】
問題文と3つの選択肢を表示します。選択肢はボタンにし、回答後は正解・不正解と解説を表示してください。一度回答したら選択肢を押せないようにし、再読み込みすると初期状態に戻してください。
【問題データ】
ここに、確認済みの問題文・選択肢・正解・解説を記載します。
【回答してほしい内容】
各ファイルのコード、保存場所、実行方法、正誤判定の説明、動作確認の項目を示してください。コードを実行していない場合は、その旨を明記してください。
「コードが出た」と「動いた」を分けて確認する
AIがコードを生成しただけでは、手元の環境で動くことは確認できていません。ファイルを保存して実行し、仕様に書いた操作を試してみましょう。
- 問題文と3つの選択肢が表示されるか。
- 正解の選択肢を押すと、正解と表示されるか。
- 不正解の選択肢を押すと、不正解と表示されるか。
- 回答後に解説が表示され、再回答できなくなるか。
- 再読み込みすると、回答前の状態に戻るか。
不具合が出た場合は、「期待した動作」「実際の動作」「再現する操作」「確認できたエラー」をまとめてAIに渡します。APIキーや個人情報が含まれるログは、そのまま貼り付けないようにしてください。
修正後は、不具合が出た操作に加えて、それまで動いていた操作も確認します。エラー表示が消えたことだけで、必要な機能まで直ったと判断しないことが大切です。
AIが作ったコードを採用するときは、変更内容とテストの根拠も確認します。仕様との照合や、既存機能への影響を調べる手順を紹介しています。
AI生成コードのレビュー方法|仕様・テスト・保守性を確認する実践手順 記事を読む →4.AIのAPIは、必要な機能が決まってから組み込む
基本動作を確認できたら、「固定の文章では対応しにくい場面があるか」を考えます。たとえば、教材作成者向けに、確認済みの解説を別の表現へ書き換える下書き機能を追加する、といった使い方です。
この場合、正誤判定は登録済みの正解を使い、AIには説明文の下書きを依頼します。判定と文章生成の役割を分けておくと、生成結果を採用しない場合でも基本機能を維持できます。
送信する情報と、結果の扱いを決める
APIを呼び出す前に、送信するデータと、返ってきた結果を使う場所を決めます。学習履歴や氏名など、今回の文章生成に必要のない情報まで送る構成にする必要はありません。
| 設計する項目 | 解説の下書き機能での例 |
|---|---|
| 入力 | 問題文、確認済みの正解と解説、対象学年 |
| AIへの依頼 | 内容を変えず、対象学年に合わせた説明案を作る |
| 出力の確認 | 正解との矛盾、条件の欠落、不適切な表現を確認する |
| 採用方法 | 教材作成者が確認してから、学習者向けに公開する |
| 失敗した場合 | 生成できなかったことを表示し、元の解説を利用できるようにする |
「内容を変えないで」と指示しても、必ず元の意味が保たれるとは限りません。また、必要な項目がそろった形式で返ってきても、解説の正しさまで保証されたわけではないため、内容の確認は別に行います。
1件の成功から、運用できるかの確認へ進む
短い解説で成功したら、条件が多い問題や、説明が長い問題でも試します。何を正しい結果とするかを先に決め、同じ例を使って、指示やモデルを変更したときの違いを比較しましょう。
文章の分かりやすさに加え、応答時間、失敗した件数、確認にかかった時間も記録します。モデル名や機能の多さだけで選ばず、自分の用途で必要な結果が得られるかを確かめてください。
5.APIキー・権限・費用を別々に管理する
秘密のAPIキーは、ブラウザへ配信しない
秘密のAPIキーを使う構成では、ブラウザから自分のサーバーへ依頼を送り、サーバー側で外部APIを呼び出します。キーはサーバーのシークレット管理機能などで保持し、配信するJavaScriptや公開リポジトリに含めません。
環境変数に入れた値でも、ビルドの設定によってブラウザ向けのコードへ埋め込まれる場合があります。「環境変数にしたから安全」と判断せず、最終的に利用者へ配信される内容を確認しましょう。
キーを誤って公開した場合は、ファイルから削除するだけでは不十分です。漏洩したキーを無効化し、必要に応じて再発行したうえで、利用履歴や影響を確認します。
APIキーを隠すことと、利用者の操作制限は別
外部APIのキーをサーバーに置いても、自分のサーバーへ誰でも無制限に依頼できれば、不正利用や費用増加につながります。利用者の確認、操作できる範囲、入力サイズや呼び出し回数の制限を設けましょう。
教材作成者だけが使う機能なら、生成用のAPIでもその権限を確認します。画面上でボタンを隠すだけでは、直接リクエストを送られた場合の制御にはなりません。
失敗時の再試行にも上限を設ける
通信が失敗したときは、原因に合わせて処理を分けます。入力や認証情報の誤りは、同じ内容を繰り返し送っても解消しないため、修正や設定確認が必要です。
一時的な障害で再試行する場合も、回数と待機時間を決めます。SDKが自動で再試行する場合は、自分で追加した処理と重なって、想定以上に呼び出していないかを確認してください。
料金の確認では、成功した依頼だけでなく、再試行や採用しなかった生成結果も含めます。通知を受け取る設定と、アプリ側で処理を停止する制限は、分けて確認しましょう。
API連携を業務の処理へ広げるときは、承認や失敗時の対応も設計します。処理の順序と、AIに任せる範囲を整理する方法を解説しています。
AIとAPI連携で業務を自動化する方法|ワークフロー設計と安全な運用の基本 記事を読む →6.自動テストとデプロイは、AIがなくても設定できる
コードを変更したときにテストを実行したり、条件を満たした変更を公開したりする仕組みは、AIを使わずに構築できます。たとえばGitHub Actionsでは、リポジトリのイベントなどをきっかけに、設定した処理を実行できます。
AIには、設定ファイルやテストコードの下書きを依頼できます。ただし、実際に何を実行し、どの条件で公開するかは、ワークフローの設定として確認する必要があります。
- テスト:正誤判定や入力チェックが仕様どおりか確認する。
- ビルド:公開に必要なファイルを生成できるか確認する。
- 公開:テスト結果や承認など、決めた条件を満たした変更を反映する。
- 復旧:問題が起きたときに、直前の動作する版へ戻す手順を用意する。
AIが作ったテストも、期待する結果が正しいかを見直しましょう。実装の誤りと同じ誤りをテストに含めてしまうと、テストが成功しても仕様を満たしていない場合があります。
7.開発効率は、確認・修正・運用まで含めて測る
コードが短時間で生成されても、内容を理解したり、不具合を直したりする時間が増える場合があります。AIの効果を確認するときは、生成にかかった時間だけを比較しないようにしましょう。
| 確認する項目 | 記録する内容の例 |
|---|---|
| 依頼の準備 | 仕様や関連コードを整理した時間 |
| 生成・修正 | コードの生成と、追加の修正依頼にかかった時間 |
| レビュー・テスト | 動作確認、差分確認、不具合対応にかかった時間 |
| 運用 | 障害対応、問い合わせ、更新作業の負担 |
| 費用 | 開発支援ツール、API、サーバーなどの利用料金 |
比較するときは、機能の範囲と確認基準をそろえます。確認を省いて早く終えた作業と、十分に確認した作業を比べても、開発方法の違いによる効果は判断しにくくなります。
手戻りが多いなら、依頼する範囲を小さくする、仕様を具体化する、使うAPIを減らすなど、原因に合わせて調整します。AIを使う工程を増やすこと自体を目標にせず、完成までの負担がどう変わったかを見てください。
8.まずは1つの機能を完成させ、必要な連携を追加する
AIとAPIを使った開発では、作りたい機能を具体化し、コードの動作と外部サービスとの連携を確認することが大切です。最初は登録済みのデータで動く小さなアプリを作り、その後に必要なAPIを追加する進め方も選べます。
クイズアプリなら、「1問を表示する」「回答を判定する」「解説を表示する」までを確認してみましょう。そのうえで文章生成や保存機能が必要かを考えると、追加する理由と確認する範囲を明確にできます。
参考資料
- GitHub Docs:GitHub Copilotのコード提案に関する用途・制約・確認事項
- GitHub Docs:GitHub Actionsの基本
- OWASP:REST Security Cheat Sheet
- OWASP:Secrets Management Cheat Sheet
Learning Tools
記事を検索したい方はここから!
記事を検索
関連記事や、今の内容に近いテーマをすぐに検索できます。
例: AI / 情報Ⅰ / Python / 統計 / 資格 / 学習法