AIアプリ自作入門（ノーコード）｜入力→AI部品→出力をつないで現場に渡せるアプリを作る

「AIで何か作れないか、考えておいて」。上からそう言われて、手が止まっていませんか。ChatGPT のようなAIが便利なのは、もう分かっています。問い合わせへの返信文だって、自分のチャット画面に貼り付ければ、下書きをすぐ返してくれる。けれど、それを「チームの誰もが毎日使える形」にしようとした瞬間、見えない壁にぶつかります。自分のチャット画面で個人的に使うのと、現場の人に配れるアプリにするのとの間には、深い溝があるように感じる。そして「アプリを作るなんて、結局エンジニアの仕事でしょう」と、また手が止まる。

この壁を、コードを書かずに越えるのが、本講座のテーマです。AIアプリ ノーコード 作り方の出発点は、実はとてもシンプルです。AIアプリ自作とは、AIを「自分のチャット画面で使う」のをやめて、「入力 → AIに処理させる → 出力」という流れを、誰もが同じ手順で再現できる箱（アプリ）に載せることです。要るのはコードではありません。「何を入れて・何をさせて・何を返すか」を決める設計だけです。

最初に、本講座が扱う範囲と扱わない範囲をはっきりさせておきます。本講座は「ノーコードで作るアプリの箱の中に “AI機能” を組み込んで動かす」差分に一点集中します。アプリの箱そのもの——入力欄や画面、データの置き場——を作る基礎操作は、ノーコードツール入門が正本で、本講座では習得済みとみなします。AIに渡す指示文（プロンプト）の中身をどう磨くかはAIプロンプトの基本やプロンプトエンジニアリング応用へ、「入力が○○なら処理を変える」といった条件分岐や計算を足したくなったらローコード開発入門へ、外部サービスとデータを往復させる仕組みそのものはAPI入門へ送客します。これらの深掘りには、本講座では踏み込みません。

この講座を終えると、次の3つができるようになります。AIアプリの最小構成（入力 → AI部品 → 出力）を図で説明でき、チャット利用とアプリ化の違いを説明できること。ノーコードツール上で「AIを呼び出す部品」の設定欄に何を入れるかを説明でき、項目を埋められること。そして、入力欄・AI部品・出力欄をつないだ最小のAIアプリを作って、テストデータで動かし、共有できることです。

全章を通して、ひとつの題材を一段ずつ組み上げていきます。題材は「返信下書きアシスト」。問い合わせメールの文面を貼ると、返信文の下書きを返してくれる、社内向けのミニアプリです。第1章で設計図を描き、第2章でAI部品の中身を決め、第3章で実際につないで動かし、第4章で点検して同僚に渡す。この一本の糸を、最後まで追いかけます。

AIアプリ ノーコード 作り方——チャット利用とアプリ化の違いを知る

AIアプリとは「決まった入力を受け取り、AIに決まった処理をさせ、決まった形で返す箱」

AIアプリと聞くと、何か高度なものを想像するかもしれません。けれど、いちばん小さなAIアプリの正体は、こうです。「決まった入力を受け取り、AIに決まった処理をさせ、決まった形で結果を返す」。この一連の流れを、毎回同じ手順で再現できるようにした箱——それがAIアプリです。

「返信下書きアシスト」で考えてみましょう。決まった入力は「問い合わせメールの文面」。AIにさせる決まった処理は「この問い合わせに丁寧に返信する下書きを作る」。決まった形の出力は「返信文の下書き」。この3つが固定されていて、誰が使っても同じ手順で下書きが返ってくる。これが、最小のAIアプリです。

チャット利用との違いは「入力の形が決まる・処理が固定される・他人が使える」の3点

では、あなたが今やっている「チャット画面に貼り付けて使う」のと、何が違うのでしょうか。違いは3点です。

ひとつ目は、入力の形が決まること。チャットでは毎回、文面の前に「丁寧な返信を作って」と自分で書き添えています。アプリでは、入力欄に問い合わせ本文を貼るだけ。入力の形が「問い合わせ本文」に固定されます。ふたつ目は、処理が固定されること。「丁寧に返信する下書きを作る」という指示が、アプリの中にあらかじめ組み込まれていて、毎回打ち直す必要がありません。実際、ノーコード/ローコードのAIアプリでは、固定した指示（instruction）に、実行時の動的な入力を組み合わせてAIを呼ぶ構造が基本になっています（出典：Microsoft Learn「Add inputs to your prompt」「Create a prompt」）。三つ目は、他人が使えること。あなたの頭の中にある「こう頼めばいい」という暗黙の手順が、アプリの中に書き出されているので、AIに不慣れな同僚でも、入力欄に貼って実行するだけで同じ結果が得られます。

つまり、チャット利用とアプリ化の差は「速いか遅いか」ではありません。「再現できて、他人が使える形になっているか」です。

作りたいものを「入力／処理／出力」の3つに分解して1枚に書き出す

ここで、覚えて帰ってほしい型が出てきます。AIアプリを作るときは、いきなりツールを触らず、まず「入力（何を受け取る）／処理（AIに何をさせる）／出力（どう返す）」の3つに分解して、1枚の紙に書き出します。

「返信下書きアシスト」なら、入力＝問い合わせメールの本文、処理＝丁寧な返信の下書きを作る、出力＝返信文の下書き、と3行書くだけです。たったこれだけですが、この3行が、これから作るアプリの設計図になります。

つまずきやすいのは、ここで欲を出すことです。「ついでに、返信の丁寧さを5段階で選べるようにしよう」「過去のやりとりも参照させよう」と機能を盛り始めると、設計図がぼやけて、何を作っているのか分からなくなります。「AIアプリ＝高機能なチャットボット」という思い込みは、いったん脇に置いてください。最初は、入力ひとつ・処理ひとつ・出力ひとつの、最小構成に絞ります。逆に、入力と出力を決めずにツールを触り始めると、画面に部品を置いては消す堂々巡りになります。先に3行を書き出すこと。それが遠回りに見えて、いちばんの近道です。

この章の確認（演習）

自分の業務から、AIに任せられそうな題材を1つ選んでください。そして共通例にならって、「入力（何を受け取る）・処理（AIに何をさせる）・出力（どう返す）」の3点を、1枚の紙に3行で書き出しましょう。書き終えたら、機能を盛りすぎていないか、入力と出力がそれぞれ1つに絞れているかを見直してください。

AIを呼び出す部品を理解する——設定欄の4枠に何を入れるか

AI部品の設定は「使うAI／渡す値／処理／出力先」の4枠に整理できる

第1章で描いた設計図を、いよいよツール上の「AIを呼び出す部品」に落とし込みます。ノーコードツールには、AIに処理を頼むための部品（製品によって「プロンプト」「AIタスク」などと呼び名は違います）が用意されていて、その設定欄を埋めると、AIがあなたの代わりに処理をしてくれます。

製品ごとに画面は違いますが、設定する中身は、突き詰めると4つの枠に整理できます。①使うAI（どのモデルに頼むか）、②渡す値（入力欄の値を何として渡すか）、③処理（AIに何をさせるかの固定の指示）、④出力先（結果をどこに出すか）。この4枠を埋めることが、AI部品を設定するということです。実際、ある製品ではAIに頼む指示を「使うモデルを選び、入力（テキストや画像）を追加し、指示を書き、結果を受け取る」形で設定し（出典：Microsoft Learn「Create a prompt」「Use your prompt in Power Apps」）、別のノーコード製品では「評価対象の列」や「抽出したい情報と、それを保存する先のデータソース」を指定します（出典：Google「Overview of AI in automations - AppSheet Help」）。呼び名や画面は違っても、4枠に収まる、という見立てで読み解けば迷いません。

入力欄の値を、AI部品の「渡す値」に紐づける

4枠のうち、つまずきが集中するのが②渡す値です。これは「画面の入力欄に入った値を、AIに渡すもの」として結びつける設定です。

「返信下書きアシスト」なら、問い合わせ本文を入れる入力欄の値を、AI部品の「渡す値」に紐づけます。ノーコード/ローコードのAIアプリでは、こうして実行時に動的な値（ユーザーが入れたテキストなど）をAIに渡せるようになっていて、固定の指示と、その場で渡す値を、別々に持つのが基本です（出典：Microsoft Learn「Add inputs to your prompt」）。ここで紐づけを忘れると、AIには空っぽの値が渡り、「何も入れていないのに下書きが返ってこない」という状態になります。入力欄を置いただけで満足せず、その値をAI部品に渡す線を、必ず引いてください。

処理（固定の指示）はアプリの中に置く——自分の頭の中に置いたままにしない

③処理は、AIに何をさせるかの「固定の指示」です。「返信下書きアシスト」なら、「この問い合わせに丁寧に返信する下書きを作る」がそれにあたります。

大事なのは、この指示をアプリの中に書き込んでおくこと。チャット利用のクセで、指示を自分の頭の中に置いたまま、アプリには入力欄しか作らない——これが、よくある失敗です。それでは「他人が使える」状態になりません。指示はアプリの中に固定し、誰が使っても同じ処理が走るようにします。なお、この固定の指示は、おおまかに「何をさせるか（指示）」と「そのために必要な背景情報（文脈）」に分けて書くと、AIに伝わりやすくなります（出典：Microsoft Learn「Create a prompt」）。

ただし、本章で扱うのは、この処理を「どこに置くか」までです。指示の文面そのものをどう書けば安定して良い下書きが返るか——という作り込みは、AIプロンプトの基本やプロンプトエンジニアリング応用の領域です。本講座では立ち入りません。

この章の確認（演習）

第1章で書いた「入力・処理・出力」の3行を、今度は4枠の表に落とし込んでください。使うAI（どのモデルに頼むか）・渡す値（どの入力欄の値を渡すか）・処理（どんな固定の指示にするか）・出力先（どこに結果を出すか）の4つを、それぞれ1行で埋めます。埋まらない枠があれば、そこが、まだ決まっていない設計です。

入力・AI部品・出力をつないで最小アプリを動かす

最小構成は「入力欄1つ・AI部品1つ・出力欄1つ・実行ボタン1つ」

設計図と4枠が決まったら、いよいよ組み立てです。といっても、最初に作るのは最小構成だけ。「入力欄1つ・AI部品1つ・出力欄1つ・実行ボタン1つ」、これだけです。

「返信下書きアシスト」なら、問い合わせ本文を入れる入力欄、丁寧な返信を作るAI部品、下書きを表示する出力欄、そして処理を走らせる実行ボタン。この4つを、線でつなぎます。AIアプリは「書く」のではなく「つなぐ」もの——入力と出力さえ決まっていれば、間にAIを載せて、つなぐだけです。

実行ボタンからAI部品を呼び、その出力を表示欄に流す

つなぐ順番は、上流から下流へ、です。①まず入力欄を置く。②次に実行ボタンを置いて、押したらAI部品を呼ぶ設定にする。③AI部品の出力を、表示欄に流す。これで「入力欄 → 実行ボタン → AI部品 → 出力欄」という一本の流れができあがります。

たとえばある製品では、ボタンを押したときに「このAI部品を、入力欄の値を渡して呼び、返ってきた結果を表示欄に出す」という設定を、式を1行書くだけで実現できます（出典：Microsoft Learn「Use your prompt in Power Apps」）。別のノーコード製品では、ファイルや画像のアップロードをきっかけにAIの処理が走り、読み取った結果をデータの行に直接保存する形になっています（出典：Google「Overview of AI in automations - AppSheet Help」）。製品によって「ボタンで呼ぶ」か「アップロードで起動する」かは違いますが、「実行のきっかけ → AI部品 → 出力先」という流れは共通です。

つまずきやすいのは、この実行ボタンとAI部品のつなぎが抜けることです。入力欄と出力欄は置いたのに、ボタンを押しても何も起きない——たいてい、ボタンからAI部品を呼ぶ線が引かれていません。「押したら何が起きるか」を、必ず設定してください。

テストデータ1件で、まず動かしてから機能を足す

つなぎ終えたら、いきなり本番の問い合わせで試してはいけません。まずは、短くて素直なテストデータ1件で動かします。たとえば「商品の納期を教えてください」という一文を入力欄に貼って、実行ボタンを押し、下書きが返ってくることを確認します。実際、AIアプリは作ったあとに動作を確認する手順が用意されていて、入力を入れて、出力欄に結果が出るかを見て、初めて「動いた」と言えます（出典：Microsoft Learn「Use your prompt in Power Apps」）。

なぜ最小データから始めるのか。それは、うまくいかなかったときに原因を切り分けやすいからです。いきなり長文の複雑な問い合わせで試すと、つなぎが悪いのか、指示が悪いのか、入力が長すぎるのか、原因が分かりません。まず最小形を確実に動かす。それから機能を足す。この順番が、遠回りに見えていちばん速い道です。なお、「入力が○○なら処理を変える」といった条件分岐や計算を足したくなったら、それはローコード開発入門の領域です。外部のサービスとデータを往復させたい場合はAPI入門へ進んでください。

この章の確認（演習）

第2章で作った4枠の表のとおりに、ツール上で入力欄・AI部品・出力欄を置き、実行ボタンからAI部品を呼ぶようにつないでください。つなぎ終えたら、短いテストデータ1件（例：「納期を教えてください」）を入力欄に入れて実行し、出力欄に下書きが返ることを確認しましょう。返ってこなければ、ボタンからAI部品への線、入力欄からAI部品への線が引かれているかを見直します。

テスト・共有・改善で現場に渡せる形にする

AIの出力は毎回同じとは限らない——“だいたい使える”を複数の入力で確かめる

最小データで1回動いた。でも、それは「完成」ではありません。AIの出力は、同じ入力でも毎回まったく同じとは限らず、想定していなかった入力では、おかしな下書きを返すこともあります。だからこそ、現場に渡す前に、いくつかのパターンで点検します。

「返信下書きアシスト」なら、空の入力（何も貼らずに実行）、極端に長い入力（長文の問い合わせ）、想定外の入力（問い合わせですらない雑談）を入れてみて、それぞれで挙動を確認します。空のときにエラーで止まらないか、長文でも破綻しないか、見当違いの入力に無理やり返信を作っていないか。「どんな入力でも完璧」を目指すのではなく、「想定する入力なら、だいたい使える」ことを確かめるのが、ここでの目的です。

そして忘れてはいけないのが、AIの出力の正しさは、最後は人が確認するという前提です。AIが作った返信の下書きを、中身を見ないまま顧客に送ることはできません。実際、AIによる自動化では、出力を人がレビューすることが公式にも推奨されています（出典：Microsoft Learn「Create a prompt」ほか関連ドキュメント「Human review for automation with a prompt」）。アプリはあくまで下書きを作るところまで。送る前に人が目を通す、という運用とセットにします。

共有設定は「閲覧か編集か・誰に渡すか」を決めてからURLを発行する

点検が済んだら、同僚に渡します。ここで雑にやってしまうと、後で困ります。共有のときに決めるべきは、「誰に渡すか」と「その人に何を許すか」です。

多くのツールでは、共有範囲を「誰でも（公開）」と「特定の人に限定」から選べます。社内で使うアプリや、扱う情報に配慮が要るアプリは、誰でもアクセスできる公開設定は避けるのが基本で、限定共有にはサインインを求めるのが標準です（出典：Google「Share: The Essentials - AppSheet Help」）。さらに、渡す相手ごとに「使うだけ」「閲覧・複製まで」「編集も可」といった権限を選べる製品もあります（出典：同）。ここでやりがちな失敗が、面倒だからと「誰でも編集できる」設定で配ってしまうことです。アプリを使ってほしいだけの同僚に編集権限まで渡すと、設計を壊されたり、意図せず情報が広がったりします。「使ってもらうだけなら、使うだけの権限」。範囲と権限を決めてから、URLを発行してください。

なお、多くのツールでは、共有して本番運用に移す前に、テストして公開前の確認（デプロイチェックのような点検）を通す手順が用意されています。公開して初めて動く機能もあるため、「試作の状態」と「公開した状態」は分けて考えます（出典：Google「Deploy: The Essentials - AppSheet Help」）。また、入力してよいデータの線引きや、社内での共有権限のルールは、組織の方針に従ってください。

使った人の声を1つ集めて、改善点を1つに絞って直す

共有したら、それで終わりにせず、使った人の声を1つ集めます。「敬語が硬すぎる」「もう少し短い下書きがいい」——どんな小さな声でも構いません。

声を受け取ったら、改善点を1つに絞って直します。「敬語が硬すぎる」なら、第2章で固定した処理（指示）の置き場所に戻り、指示を少し調整して、また点検し直す。一度にあれもこれもと直すと、何が効いたのか分からなくなります。1回につき1点。点検 → 共有 → 声を1つ集める → 1点改善、このループを回して初めて、AIアプリは「現場に渡せるもの」になります。

この章の確認（演習）

自分のアプリを、3パターンのテストデータ（例：空の入力・長すぎる入力・想定外の入力）で点検してください。それぞれの挙動を書き留め、見つかった改善点を1つだけ書き出します。あわせて、このアプリを誰に・どの権限（使うだけ／編集も可）で共有するか、その方針も1行で記しましょう。