AIの関数呼び出し入門｜今日から安全に動かす5つの実践手順

AIに最新情報を聞いたら、それらしい嘘を返された。社内データを答えてほしいのに、記憶だけで話してしまう。計算や予約や在庫確認まで任せたいのに、どこから作ればいいかわからない。そんな場面で必要になるのがAIの関数呼び出しです。仕組みを正しく押さえると、AIは「知っているふりをする存在」から「必要な道具を選び、正しい処理につなぐ窓口」に変わります。

AIの関数呼び出しとは何か

AIの関数呼び出しとは、ユーザーの言葉を読んだAIが、必要に応じて外部の処理を使うための仕組みです。たとえば「今日の東京の天気を教えて」と入力されたとき、AIの記憶だけでは正確な現在の天気はわかりません。そこでAIは「天気を取得する処理を使うべきだ」と判断し、地域名などの必要な情報を指定します。
大事なのは、AIが実際に天気サイトやデータベースを勝手に操作するわけではないという点です。AIは「この関数を、この引数で呼ぶべきです」という指示を返します。その指示を受け取って実行するのは、アプリ側のプログラムです。
この役割分担を間違えると、原因調査で迷います。画面上で関数名が返っているのに結果が出ないなら、AIではなく、アプリ側の実行処理、認証情報、返却データ、エラー処理を確認します。反対に、間違った関数名や不自然な引数が返るなら、関数の名前、説明文、入力項目の設計を直します。

たとえるなら受付係と専門担当の関係

AIは受付係です。ユーザーの曖昧な言葉を受け取り、「これは料金確認です」「これは在庫確認です」「これは通常の会話です」と振り分けます。関数は専門担当です。料金確認なら料金表を見る、在庫確認なら在庫データを見る、予約なら予約システムへ登録する、という具合です。
受付係に「何でもやって」と言うと混乱します。逆に「料金を聞かれたら料金確認へ」「在庫を聞かれたら在庫確認へ」と道具の使い方を明確にすると、安定して動きます。

最初に理解すべき3つの流れ

初心者は、いきなり複雑なエージェントを作るより、1回の質問で1つの道具を使う流れから始めると失敗しにくくなります。最初の実装は、次の順番で考えると画面上の結果を確認しやすくなります。

この流れで作ると、「AIの判断」「アプリ側の実行」「最終回答」の3か所を分けて確認できます。エラーが出たときも、どこで止まっているかを見つけやすくなります。

画面で確認すべきポイント

テスト画面で「東京の天気は？」と入力したとき、まず確認するのは最終回答ではありません。AIが天気取得用の関数名を選んでいるか、入力値に東京が入っているかを見ます。ここが正しければ、AIの判断はおおむね成功です。
次に、アプリ側で実行した結果を見ます。天気APIから気温、降水確率、天候などが返っているなら、外部処理も成功です。最後に、その結果をAIに渡して「東京は現在晴れ、気温は〇度です」のように答えられれば、全体の流れが完成します。

初心者が最初に作るべき関数

最初から予約変更、決済、顧客情報更新のような失敗できない処理を作るのは危険です。まずは、実行しても被害が出にくく、結果を目で確認しやすい関数を選びます。
おすすめは、天気取得、商品検索、社内FAQ検索、料金計算、営業日の確認です。これらは読み取り中心なので、万が一AIが間違えても重大な更新につながりにくいです。

書き込み処理は最後に回す

予約作成、注文確定、顧客情報変更、メール送信などは、ユーザーの確認画面を必ず挟みます。たとえばAIが「予約作成関数」を選んだ場合でも、すぐに予約を確定させず、「4月30日14時に東京店で予約します。確定しますか？」と表示します。ユーザーが確定ボタンを押した後にだけ実行すると、誤操作を防げます。
この確認画面を入れるだけで、初心者が作るAIアプリの安全性は大きく上がります。AIに判断させる部分と、人間が最終承認する部分を分けるのが実務では重要です。

失敗しにくい関数設計のコツ

AIの関数呼び出しでよくある失敗は、AIの性能だけが原因ではありません。多くの場合、関数の設計が曖昧です。特に、関数が大きすぎる、説明文が短すぎる、入力項目が自由すぎる、この3つが原因になります。

失敗しやすい設計	直し方
顧客管理、注文更新、商品検索を1つの関数にまとめている	顧客取得、注文更新、商品検索のように目的ごとに分けます。
説明文に「情報を取得する」としか書いていない	どの場面で使い、どの場面では使わないかまで書きます。
入力値を自由記述にしている	選択肢、必須項目、数値範囲を決めて、AIが迷う余地を減らします。

1つの関数は1文で説明できる大きさにする

「この関数は何をするものですか？」と聞かれて、1文で説明できないなら大きすぎます。「商品名から在庫数を取得する」「郵便番号から送料を計算する」「予約番号から予約状況を取得する」のように、目的が一目でわかる大きさにします。
ただし、細かく分けすぎても失敗します。たとえば毎回必ず「商品検索」と「在庫確認」を連続で行うなら、まとめた関数にしたほうが安定することがあります。判断基準は、ユーザーの目的から見て自然なひとまとまりかどうかです。

説明文には使う場面と使わない場面を書く

関数の説明文は、AIにとって操作マニュアルです。「料金を取得する」だけでは足りません。「ユーザーが目的地と曜日を指定して交通費を聞いたときに使う。観光地の説明だけを求めている場合は使わない」のように書くと、AIは判断しやすくなります。
似た関数が複数ある場合は、違いを明確にします。商品検索と注文検索があるなら、商品検索は購入前の商品情報、注文検索は購入後の配送状況、と分けて書きます。ここを曖昧にすると、AIは近そうな関数を選んでしまいます。

入力項目を厳しくすると安定する

AIは、入力項目が自由すぎると勝手に値を作ることがあります。存在しない項目名を入れたり、数値欄に文章を入れたり、選択肢にない値を返したりします。これを防ぐには、スキーマを厳しくします。スキーマとは、入力データの形を決める設計図です。
たとえばステータス欄なら、自由入力にせず、「未対応」「対応中」「完了」の3つから選ばせます。日付欄なら日付形式だけを受け付けます。金額欄なら数値だけを受け付けます。必須項目と任意項目も分けます。

厳格モードと二重チェックを使う

最近のAI開発では、決めた形式から外れた出力を減らすために、厳格な構造化出力を使う設計が一般的になっています。ただし、形式が正しくても、業務上おかしい値は入り得ます。たとえば日付形式は正しくても、過去の日付で予約しようとすることがあります。
そのため、アプリ側でも二重チェックを入れます。予約日が過去なら実行しない、在庫数を超える注文数なら確認画面を出す、メール送信前には宛先と本文を表示する。このように、AIの出力をそのまま信じず、最後はプログラム側で守ります。

エラーを隠さない設計が実務では強い

外部APIは必ず失敗します。認証切れ、通信エラー、タイムアウト、メンテナンス、形式変更、入力不足が起きます。初心者がやりがちなのは、失敗したときに「処理できませんでした」だけをAIに返すことです。これではAIも次の行動を判断できません。
失敗時は、何が起きたかを短く返します。「認証エラーです」「指定された商品IDが存在しません」「天気APIが時間内に応答しませんでした」のように返すと、AIはユーザーに確認を求めたり、別の入力を促したりできます。

自動リトライには上限を付ける

通信エラーなら再試行で直ることがあります。ただし、上限なしの再試行は危険です。API料金が増え、同じ失敗を繰り返し、ユーザーを待たせます。最初は最大2回か3回にします。それでも失敗する場合は、「現在外部サービスに接続できません。時間を置いて再試行してください」と表示します。
この表示があるだけで、ユーザーは自分の入力が悪いのか、システム側の問題なのかを判断できます。AIアプリでは、失敗をゼロにするより、失敗したときに迷わせないことが大切です。

ツールを増やしすぎると賢くなるとは限らない

関数を増やすほどAIが便利になるように見えますが、実際は逆に不安定になることがあります。AIに渡す関数定義が増えると、選択肢が多くなり、似た関数を取り違えやすくなります。さらに、関数定義の説明文も毎回の処理に含まれるため、コストや応答時間にも影響します。
最初は5個以内に絞ると管理しやすいです。慣れてきても、1つの画面や1つの業務で使う関数は多くしすぎないほうが安定します。大量の機能が必要な場合は、問い合わせ対応用、社内検索用、予約処理用のように役割ごとに分けます。

複雑な作業ではコード実行型との使い分けも考える

複数の検索、絞り込み、計算、保存を何度も繰り返す作業では、関数を1回ずつ呼ぶ方式だけだと往復が増えます。この場合は、AIに短い処理手順やコードを作らせ、管理された安全な実行環境で動かす方式が向いていることがあります。
ただし、初心者が最初からコード実行型に寄せる必要はありません。まずは関数呼び出しで「AIがどの道具を選ぶか」を理解します。そのうえで、複雑な一括処理が増えてきたら、コード実行やワークフロー管理を検討します。

AIの関数呼び出しに関する疑問解決

AIの関数呼び出しで最初に混乱しやすいのは、「通常のチャット」「構造化出力」「外部ツール利用」の違いです。通常のチャットは、AIが文章で答えます。構造化出力は、決まった形式のデータを返します。関数呼び出しは、外部処理を使うべき場面で、関数名と入力値を返します。
たとえばアンケート文から氏名とメールアドレスを抜き出すだけなら、構造化出力で十分です。現在の在庫を確認する、顧客データを検索する、送料を計算する、予約枠を取得するなら、関数呼び出しを使います。

チャットボットに入れると何が変わるのか

関数呼び出しがないチャットボットは、質問に対して文章を返すだけです。関数呼び出しを入れると、ユーザーの発言から必要な処理を判断し、在庫確認、見積もり、予約候補の提示、社内文書検索などにつなげられます。
たとえば「来週の金曜に大阪店で空いてる時間ある？」と入力された場合、AIは日付、店舗、目的を読み取り、予約枠取得の関数を選びます。アプリ側が空き時間を取得し、AIが「10時、13時、16時が空いています」と返します。ユーザーは自然な会話のまま、実際の業務データに基づく回答を受け取れます。

初心者が最初につまずく落とし穴

落とし穴1テスト画面では動いたのにアプリ側で何も起きない

AIのテスト画面で「東京の天気を教えて」と入力すると、get_weatherのような関数名とlocationという入力値が表示される。そこで「よし、動いた！」と思ってアプリに組み込むと、チャット画面では普通の文章だけが返ってきて、天気データが一切表示されない。このつまずきはかなり多いです。
原因は、AIが返しているのは実行結果ではなく実行指示だからです。AIは「この関数を呼ぶとよさそう」と言っているだけで、実際に天気API（天気情報を取る外部窓口）へ接続する処理は、アプリ側に書く必要があります。
こうすれば一発で解決します。

天気確認の場面で、AIの返した関数名をアプリ側の処理に接続すると、ただの「呼び出し指示」が実際の天気回答に変わります。ここをつなげていないと、どれだけ関数定義をきれいに書いても画面上では何も起きません。

落とし穴2関数名は返るのに入力値がズレる

商品検索のテストで「赤いスニーカーある？」と入力したのに、AIがcolorにredではなくsneakerを入れてしまう。あるいはcategoryに赤、keywordに靴、sizeに空欄を入れて、検索結果がゼロになる。画面上では関数が呼ばれているのに、結果だけがズレて見える状態です。
原因は、入力項目の名前と説明がAIにとってわかりにくいからです。parameter（入力欄の名前）が曖昧だと、AIは人間の感覚で「たぶんここに入れるのかな」と推測します。
こうすれば一発で解決します。まず、入力項目名を短くしすぎないことです。qだけではなくsearch_keyword、cだけではなくcolor_nameのように、見ただけで意味がわかる名前にします。次に、それぞれの説明文へ「何を入れるか」と「何を入れないか」を書きます。
商品検索の場面で、color_nameに「色だけを入れる。商品名やサイズは入れない」と書くと、AIは赤をcolor_nameへ入れ、スニーカーをsearch_keywordへ入れやすくなります。さらに、色をred、black、white、blueの4種類だけに制限すると、表記ゆれも減ります。
初心者は、まず入力項目を3つ以内にしてください。商品検索なら、search_keyword、color_name、max_priceくらいで十分です。最初からサイズ、ブランド、在庫店舗、発送日、性別、素材まで入れると、AIも自分も確認がしんどくなります。

落とし穴3エラー時にAIが変な言い訳をする

APIキー（外部サービスを使うための鍵）が間違っているのに、AIが「現在の東京は晴れです」と言ってしまう。データベース（情報をしまっておく箱）に接続できていないのに、「在庫はあります」と返してしまう。初心者にとって一番怖いのは、この「失敗しているのに成功っぽく見える」状態です。
原因は、エラー情報をAIに渡していないことです。アプリ側では失敗しているのに、AIには「何も返さない」または「空の結果だけ返す」状態になっているため、AIが会話を続けるためにそれらしい文章を作ってしまいます。
こうすれば一発で解決します。外部処理が失敗したら、成功時と同じように、失敗内容を短い文章でAIへ返します。たとえば「天気APIから応答がありません」「APIキーが無効です」「商品IDが存在しません」のように返します。
天気取得の場面で、通信が10秒以内に終わらなければ「天気情報の取得に失敗しました。時間を置いて再試行してください」と返すようにすると、AIは勝手に天気を作らず、ユーザーへ確認メッセージを出せます。さらに、同じ処理を最大2回まで再試行し、3回目で止める設定にすると、無駄な料金や待ち時間も防げます。

知っているとできるの差を埋める実践ロードマップ

1日目何を作るかを1つに絞る

所要時間は15分です。まずメモアプリを開いて、「ユーザーが入力する言葉」「AIに選ばせたい関数」「画面に表示したい結果」の3つを書きます。
たとえば「東京の天気を教えて」と入力されたら、get_weatherを選び、「東京の天気は晴れです」と表示する。この1本だけで十分です。最初から予約、検索、計算を全部入れないでください。
完了の判断基準は、1つの質問に対して1つの関数だけが決まっていることです。「これもできたら便利」は全部あと回しでOKです。

2日目関数の名前と入力項目を紙に書く

所要時間は20分です。コードを書く前に、関数名、説明文、入力項目を紙かメモに書きます。
天気取得の場面で、関数名をget_weatherにし、入力項目をlocationだけにすると、AIは地域名を入れる場所で迷いにくくなります。説明文には「ユーザーが現在または指定地域の天気を聞いたときに使う。観光地紹介だけなら使わない」と書きます。
完了の判断基準は、その関数を知らない友人に見せても「これは天気を取るやつだね」と3秒で伝わることです。

3日目固定データでニセの実行結果を返す

所要時間は30分です。まだ本物のAPIにはつながなくて大丈夫です。get_weatherに東京が来たら「晴れ、22度」、大阪が来たら「曇り、20度」のように、固定の結果を返します。
天気取得の場面で、東京と入力すると固定で晴れが返るようにすると、外部サービスの接続ミスに邪魔されず、AIの関数選択だけを確認できます。
完了の判断基準は、「東京の天気は？」と入力したときに、get_weatherが選ばれ、locationに東京が入り、固定結果を使った回答が表示されることです。

4日目間違った質問を10個入れてみる

所要時間は25分です。正しい質問だけではなく、わざとズレた質問を入れます。「東京の観光地を教えて」「昨日の気分は？」「大阪のラーメン屋は？」のように、天気と関係ありそうで関係ない質問を10個試します。
観光地紹介の場面で、天気関数が呼ばれなければOKです。逆に呼ばれたら、説明文に「観光地、飲食店、旅行プランだけを聞かれた場合は使わない」と追記します。
完了の判断基準は、10問中8問以上で、関数を使うべき質問と使わない質問を正しく分けられることです。

5日目エラーをわざと起こす

所要時間は20分です。locationが空欄だった場合、未対応の地域だった場合、処理に失敗した場合の3パターンを作ります。
天気取得の場面で、locationが空欄なら「地域名が必要です」と返します。未対応地域なら「その地域の天気は取得できません」と返します。処理失敗なら「天気情報の取得に失敗しました」と返します。
完了の判断基準は、失敗時にAIが嘘の天気を言わず、ユーザーに次の入力を促せることです。

6日目本物のAPIにつなぐ

所要時間は45分です。ここで初めて本物のAPI（アプリ同士をつなぐ窓口のようなもの）につなぎます。APIキーを設定し、固定データを返していた部分を、外部サービスから取得した結果に置き換えます。
天気取得の場面で、東京と入力すると外部サービスから実際の天気データが返り、それをAIが自然な日本語に直せばOKです。
完了の判断基準は、同じ質問を3回試して、3回ともエラーなく回答が返ることです。もし1回でも失敗したら、まずAPIキー、地域名の形式、通信エラーの3点だけを確認します。

7日目確認画面とログを入れる

所要時間は40分です。ログ（あとから確認できる記録）に、ユーザーの質問、AIが選んだ関数名、入力値、実行結果、エラー内容を残します。
天気取得の場面で、画面には自然な回答を表示し、裏側のログには「get_weather、location=東京、result=晴れ」のように残します。これがあると、失敗したときに原因を1分で追えます。
完了の判断基準は、1回の質問に対して、関数名、入力値、結果の3つがログで確認できることです。

現実でよくあるあるある失敗と専門家の対処法

失敗1便利そうだから関数を10個以上いきなり登録する

初心者がやりがちなのは、「天気も、在庫も、予約も、メールも、予定表も、請求書もできるAIにしたい」と考えて、最初から10個以上の関数を入れることです。テストしてみると、AIが在庫確認の場面で商品検索ではなく注文検索を呼んだり、メール作成の場面で送信まで進めようとしたりします。
根本原因は、選択肢が多すぎることです。人間でも10個の似たボタンが並んでいたら迷います。AIも同じで、似た説明の関数が多いほど取り違えます。
専門家なら、まず3個までに減らします。読み取り専用の関数だけにして、書き込み系は外します。たとえば商品検索、在庫確認、料金計算の3つだけにします。メール送信や予約確定は、後から確認画面付きで追加します。
予防策は、最初の2時間は「増やす作業」を禁止することです。1つの関数が安定して10回連続で動くまで、次の関数を追加しません。商品検索の場面で、10回中9回以上正しい検索結果が返るようになってから、在庫確認を追加します。

失敗2AIに最終決定まで任せてしまう

「予約しておいて」と言われたら、そのまま予約を確定する。「この内容でメール送って」と言われたら、そのまま送信する。動いた瞬間は感動しますが、1回でも日時や宛先を間違えると信用を失います。
根本原因は、判断と実行の境界が曖昧なことです。AIは自然文の理解が得意ですが、責任が発生する操作を無確認で確定させる設計には向いていません。
専門家なら、危険度を3段階に分けます。読み取りは即実行、下書きは作成まで、確定処理は確認画面を必須にします。予約作成の場面で、AIが日時と店舗を読み取ったら、まず「4月30日14時、東京店で予約します。確定しますか？」と表示します。ユーザーが確定を押したときだけ、予約APIを実行します。
予防策は、書き込み処理の関数名にconfirm_requiredのような印を付けることです。さらにアプリ側で、confirm_requiredが付いた関数は必ず確認画面を通すルールにします。AIの返答だけで実行しない仕組みにしておくと、うっかり事故を防げます。

失敗3うまくいかない原因を全部AIのせいにする

「AIがバカだから動かない」と感じる場面があります。でも実際には、APIキーが間違っている、関数名がコード側と一致していない、入力項目の名前がズレている、エラーを握りつぶしているだけ、ということが多いです。
根本原因は、確認する順番が決まっていないことです。最終回答だけを見ていると、AIの判断が悪いのか、外部処理が失敗しているのか、アプリ側の接続が切れているのかわかりません。
専門家なら、必ず3分割で確認します。まずAIが正しい関数名を返しているかを見る。次に入力値が正しいかを見る。最後にアプリ側の実行結果を見る。この順番にすると、原因の場所がかなり絞れます。
予防策は、毎回ログを見ることです。チャット画面だけで判断しないでください。商品検索の場面で、ユーザーが「赤いスニーカー」と入力したら、ログにsearch_products、keyword=スニーカー、color=赤と出ているか確認します。ここまで合っているのに検索結果がゼロなら、AIではなく商品データ側を見ます。

ぶっちゃけこうした方がいい！

ぶっちゃけ、初心者は最初から「すごいAIエージェント」を作ろうとしなくていいです。むしろ、それをやるとほぼ止まります。最短で結果を出したいなら、1つの質問、1つの関数、1つの結果だけに集中するのが一番コスパいいです。
最初の題材は、天気でも在庫でも料金でも何でもいいですが、個人的には「料金計算」か「在庫確認」がわかりやすいです。理由は、結果が数字で出るからです。数字は間違いに気づきやすい。AIがそれっぽい文章でごまかしても、料金が1000円なのか10000円なのかはすぐ見抜けます。
ぶっちゃけ、最初の1日はAPI接続もしなくていいです。固定データで十分です。東京なら1000円、大阪なら2000円、福岡なら3000円、みたいな雑なデータで構いません。料金確認の場面で、ユーザーが「大阪までいくら？」と入力し、AIがget_priceを選び、destinationに大阪を入れ、2000円と返せたら、その時点でかなり大きな一歩です。
それより大事なのは、AIがどこで判断し、アプリがどこで実行しているかを目で見ることです。ここが見えると、次に詰まっても自力で直せるようになります。逆に、ここが見えないまま本物のAPIやデータベースにつなぐと、エラーが起きた瞬間に完全に迷子になります。
最初は見た目も気にしなくていいです。きれいなチャットUI（会話画面）を作るより、ログを見やすくしてください。1回の入力ごとに、関数名、入力値、実行結果、エラーの4つが見えるだけで十分です。デザインに2時間かけるより、ログに20分かけたほうが上達は早いです。
ぶっちゃけ、書き込み系も最初はやらなくていいです。メール送信、予約確定、注文作成、顧客情報更新は、動くと楽しいけれど事故りやすいです。まずは読み取りだけ。検索する、確認する、計算する。この3つだけで、AIの関数呼び出しの基本は十分身につきます。
おすすめの最短ルートはこうです。まず30分で固定データの料金確認を作る。次に30分で「関係ない質問では関数を呼ばない」ように説明文を直す。次の30分でエラー時の返答を作る。ここまでで合計90分です。この90分を雑にでもやり切ると、説明を10本読むより理解が深くなります。
最後に、本音を言うと、初心者が一番伸びる瞬間は「動いた瞬間」ではありません。「あれ、なんで変な関数を呼んだんだ？」とログを見て、説明文を1行直して、次のテストで正しく動いた瞬間です。そこではじめて、AIをただ使う側から、AIの動きを設計する側に変わります。
だから最初のゴールは、完璧なAIアプリではなく、1つの関数を10回中9回正しく呼ばせることにしてください。これができれば、2個目、3個目の関数はかなり楽になります。難しい言葉を全部覚えるより、1つの小さな成功パターンを作るほうが、今日から動ける近道です。

よくある質問

AIの関数呼び出しはプログラミング初心者でも使えますか？

使えます。ただし、最初から本番システムにつなぐのではなく、固定のサンプルデータを返す関数から始めます。たとえば「東京なら晴れを返す」「商品Aなら在庫12個を返す」という小さな処理で、AIが正しい関数名と入力値を返すか確認します。ここで流れを理解してから、本物のAPIやデータベースにつなぐと安全です。

AIが間違った関数を選ぶときはどう直せばいいですか？

まず関数名を具体的にします。searchではなくsearch_products、updateではなくupdate_reservationのように、目的がわかる名前にします。次に説明文へ「使う場面」と「使わない場面」を追加します。最後に似た関数を減らします。似た道具が多いほどAIは迷います。

関数呼び出しを使えば嘘の回答はなくなりますか？

大きく減らせますが、ゼロにはなりません。外部データが古い、関数の返却結果が不完全、AIへの戻し方が曖昧、といった原因で誤回答は起こります。重要な処理では、参照したデータの日時、取得できなかった項目、確認が必要な条件を画面に表示します。ユーザーが根拠を確認できる設計にすると、実用性が上がります。

どのAIサービスでも同じように作れますか？

基本の考え方は同じです。ただし、ツール定義の書き方、返ってくる形式、厳格モードの指定方法、エラーの扱いはサービスごとに違います。複数サービスを使う場合は、アプリ内部で共通の形式に変換する層を作ると保守しやすくなります。最初は1つのサービスに絞り、動く形を作ってから広げるほうが失敗しにくいです。

まとめ

AIの関数呼び出しは、AIにすべてを任せる魔法ではありません。ユーザーの言葉を読み取り、必要な道具を選ばせ、実行はアプリ側で安全に管理するための仕組みです。
今日から始めるなら、まず読み取り専用の小さな関数を1つ作ります。関数名は目的がわかる名前にし、説明文には使う場面と使わない場面を書きます。入力項目は自由にせず、必須項目、型、選択肢を決めます。実行結果とエラーはAIに戻し、最終回答の前に画面で確認します。
この順番なら、AIがどこまで判断し、プログラムがどこから守るべきかがはっきりします。小さく動かして、間違った部分を直し、確認画面を入れ、少しずつ本番の処理に近づける。その進め方が、初心者にとって一番安全で、今日から実際に手を動かせる近道です。