非技術者が今作れるAIアプリ

「AIでアプリを作る」とは実際にどういうことか

多くの非技術系ビルダーにとって、「AIでアプリを作る」というのは新しいモデルを発明することを意味しません。通常は ChatGPT や他の大規模言語モデル（LLM）などのAIサービスをシンプルなアプリのラッパー（フォーム、チャットボックス、スプレッドシート、オートメーション）と組み合わせる ことを指します。AIがあなたのデータで有用な仕事をするようにする、というイメージです。

イメージは AI + つなぎ：

• AI は言語処理に強いタスクを担当します：要約、ドラフト作成、フィールド抽出、分類、書き換え。
• つなぎ（glue） は入力を出力に結び付けます：ノーコードツール、ワークフローオートメーション、データベースのテーブル、そしていくつかのルールです。

プロトタイプと本番アプリの違い

プロトタイプは「大抵の場合は信頼できる」もので、手間を省くために使えます。本番アプリはほぼ常に信頼できるもので、失敗時の扱いが明確です。

非技術者はプロトタイプを素早く出せることが多いですが、本番化するには追加の作業が必要になります：権限、ログ、エッジケース対応、監視、AIが誤答したときの計画など。

個人でできること vs 助けが必要なこと

個人で通常できること：

• ジョブを定義する（入力 → AIタスク → 出力）
• 実例を使ってプロンプトを書く／テストする
• ノーコードツールで簡単なUIやワークフローを作る

助けが必要になりがちなケース：

• 機密データやプライバシー要件が絡むとき
• 複数システム（CRM、メール、チケッティング）を統合する必要があるとき
• エラーが実ビジネスに影響する（支払い、コンプライアンス）とき

「はじめてのAIアプリ」のクイックチェックリスト

次を満たすものを選んでください：

• 狭い（一つの仕事、一つの結果）
• 確認しやすい（人がすぐに承認・修正できる）
• 低リスク（ミスは迷惑だが高コストではない）
• 繰り返し行う作業（週次・日次で出てくる）
• データ量が少ない（システム全体ではなく小さな断片で動く）

このチェックを通れば、最初の構築に適したアイデアの範囲に入っています。

今日組み合わせられる基礎要素

非技術チームがうまく作る「AIアプリ」のほとんどは魔法のような新製品ではなく、AIモデルを明確な入力、出力、いくつかの保護策で包んだ実用的なワークフローです。

1) 入力：AIに何を与えるか

AIは入力が予測可能なときに最もよく働きます。コーディングなしに集められる一般的な入力は、プレーンテキスト、アップロードファイル（PDF、ドキュメント）、フォーム送信、スプレッドシートの行、メールなどです。

コツは一貫性です：5つのよく選んだフィールドだけのシンプルなフォームは、雑多な段落を貼り付けるよりも優れた結果を出すことが多いです。

2) 出力：何を返してほしいか

非技術系で頼りやすい出力は主にいくつかのカテゴリに分かれます：

• 要約（会議メモ、長いメール、文書）
• 下書き（返信、説明文、社内メモ）
• 分類（このチケットにタグを付ける、見込み客を振り分ける）
• 構造化データ（テキストを表にする、名前／日付を抽出する、JSON風のレコードを作る）

出力形式を指定すると（例：「箇条書き3つ＋推奨アクション1つ」）、品質と一貫性が向上します。

3) 連携：結果はどこへ行くか

AIステップだけがアプリ全体ではありません。本当の価値は、カレンダー、CRM、ヘルプデスク、データベース／Sheets、他のオートメーションをトリガーするWebhookなど、既に使っているツールにつなぐことから生まれます。

たとえ1つの確実な接続だけでも（例：「新しいサポートメール → 下書き返信 → ヘルプデスクに保存」）、何時間もの時間を節約できます。

4) 人間を介した承認（Human-in-the-loop）

重要なパターンは「AIが下書きして、人が決定する」です。メール送信、記録更新、公開の前に承認ステップを入れてください。これによりリスクを低く保ちながら多くの時間を節約できます。

5) 信頼性はワークフローが作る

周辺のワークフローが曖昧だと、AIは信頼できないと感じられます。入力が構造化され、出力が制約され、承認があれば、汎用モデルでも一貫した結果が得られます。

実用的なツールに関する一言：一部の「vibe-coding」プラットフォーム（Koder.aiのようなもの）はノーコードと従来の開発の間に位置します。チャットでアプリを記述し、実際のWebアプリ（多くはReact）を生成して徐々に進化させられる—それでいて計画モード、スナップショット、ロールバックなどのガードレールを保てます。スプレッドシートの自動化が手狭になり、完全なカスタム開発が重すぎると感じたときに、非技術チームにとって有用な道になることがあります。

カテゴリ1：週末で作れる個人用ツール

個人用ツールは最も取り組みやすい出発点です。ユーザーが自分自身なので、リスクが低く、早く反復できます。週末プロジェクトの典型は：一つの明確な仕事、シンプルな入力（テキスト、ファイル、フォーム）、そして目を通して編集できる出力です。

個人の生産性アシスタント

メールの下書きを作る、自分のトーンに書き直す、箇条書きをきれいな返信に整える小さなアシスタントを作れます。重要なのは常にあなたがコントロールすること：アプリは提案するだけで、勝手に送信しないこと。

会議メモも大きな効率化ポイントです。メモ（または既にあるなら文字起こし）を与え、アクションアイテム、決定事項、未解決の質問、フォローアップメールの下書きを生成させて、出力をドキュメントやノートアプリに保存します。

資料作成・リサーチ補助（自分でソースを与える形式）

信頼できる「ブリーフィングビルダー」はネットを漫遊して出典を捏造しません。代わりに信頼するソース（PDF、集めたリンク、社内ドキュメント）をアップロードし、ツールが次を作ります：

• 1ページの要約
• テーマ別の主要な示唆
• 用語集
• 次回会議で聞くべき質問

入力を制御することで正確性を保てます。

軽量なデータクリーンナップ

スプレッドシートを扱うなら、行を分類する（例：「請求」「バグ」「機能要望」）、雑多なテキストの正規化（会社名、肩書）、メモから構造化フィールドを抽出するヘルパーを作れます。

元データを上書きせずに、新しい列（提案されたカテゴリー、クリーンな値）を追加する形で「人がチェックできる」ようにしてください。

学習・コーチング補助

営業の質問練習、面接対策、プロダクト知識のドリルなどの練習相手を作れます。チェックリストを与えて：

• クイズを出す
• 基準に照らして採点する
• より良い回答を提案する

こうした週末ツールは、何が入力で何が出力か、そして重要な用途に使う前にどのようにレビューするかを事前に定義しておくと最も効果的です。

カテゴリ2：簡単な顧客向けチャットボット

顧客向けチャットボットは、深い統合を必要としなくても有用になり得るため、立ち上げが比較的簡単です。ポイントはボットを狭く保ち、できないことを正直に示すことです。

すぐに作れるもの

良いスターターボットは、少数かつ安定した情報セットから繰り返し出る質問に答えます—一つの製品、一つのプラン、あるいは一つのポリシーページを想定してください。

• 単一製品やポリシーのFAQ／サポートボット： 「払い戻しはどうなりますか？」「プランBには何が含まれますか？」「パスワードをリセットする方法は？」
• リードの振り分けチャット： 3–6問を尋ね（会社規模、用途、緊急度など）、営業／サポート／パートナー担当に振り分ける
• 予約予約アシスタント（境界を明確に）： 意図、希望時間、タイムゾーン、連絡先を収集し、ボットが「確約」するのではなくスケジューリングツールへ渡すかサマリーをメール送信する

チャットボットと検索可能なヘルプセンターの使い分け

人が同じ質問を異なる言い回しで尋ね、会話的な「どうすればいいか教えてほしい」体験を欲するならチャットボットを使います。回答が長くスクリーンショットや手順が必要で頻繁に更新されるなら検索可能なヘルプセンターの方が適しています。

実務では、チャットボットが素早い案内を行い、確認のために該当するヘルプセンターの記事（内部リンク例：/help/refunds）へ誘導する組合せが最も良いことが多いです。

安全かつ効果的にするためのガードレール

顧客向けボットには巧妙なプロンプトよりもガードレールが重要です。

• 免責事項： 「一般的なご質問にはお答えできます。アカウント固有の問題は人間におつなぎします。」のような短い一行
• エスカレーション： 「人につなぐ」ルート（メール、フォーム、ライブチャット）を明確にし、「二重請求」「法務」「キャンセル」「セキュリティ」などのキーワードで自動トリガーする
• 制限トピック： 法的助言、医療ガイダンス、プライベートなアカウントデータへのアクセスが必要な案件は、適切な認証と監査されたワークフローがない限り拒否する

初期の成功指標はシンプルに：解決数（回答できた質問）、人への引き継ぎ率、チャット後の「役に立ったか？」フィードバックなど。

カテゴリ3：受信箱とチケットのトリアージ自動化

共有受信箱（support@、sales@、info@）や基本的なチケッティングツールがあるなら、トリアージは最も反復的な作業の一つです：読む、仕分ける、タグ付けする、転送する。これは入力がほとんどテキストで、出力が構造化フィールド＋提案返信になり得るためAIに適しています。

安全に自動化できること

実用的なセットアップ：AIがメッセージを読み → 短い要約＋タグ＋抽出フィールドを生成 → 必要に応じて下書きを作る → 人間が承認。

一般的な改善点：

• 受信メールやチケットの要約とタグ付け（例：請求、バグ、機能要望、解約リスク）
• スプレッドシート／CRMへ主要フィールドを抽出して書き込む（顧客名、会社、製品、問題タイプ、緊急度、注文番号、感情）
• 件名＋重要フレーズを比較して重複を検出（「この件はチケット#4821と同じようです」）

この流れはノーコードツールで、メールボックスやチケットキューを監視し、テキストをAIに送り、結果をヘルプデスクやGoogleシート、CRMに書き戻す形で実現できます。

下書き返信（ガードレール付き）

定型的な下書き返信は有用です：ログの要求、受領確認、手順リンクの提示、欠けている情報の要求など。

「必ず承認を挟む」ことは非交渉です：

• 下書きは作るが送信しない
• 下書きは受信箱／ヘルプデスクでレビューされる必要がある
• AIは短い「なぜそうタグ付けしたか」のメモを添えられる（例：「invoice と refund に言及しているので Billing とタグ付けしました」）

自信指標とフォールバックルール

AIを確信しているふうに見せないでください—不確実性に備えた設計を。

簡単な自信指標を定義します：

• モデルが自信スコアを返す（ツールが対応していれば）か、代理指標を使う（例えば「urgent」「can't login」「payment failed」と明示されているときだけ High とする）
• 必須フィールドが欠けている場合は Needs info とマークして質問を提案する
• コンテンツに機密トピック（返金紛争、法務、安全）が含まれる場合は特定キューに自動ルーティングし下書きはスキップする

フォールバックルールで正直さを保ちます：自信が低ければ「Uncertain」とラベル付けして人へ割り当て、静かに推測して処理を進めないようにします。

カテゴリ4：レポーティングとドキュメントアシスタント

レポーティングは非技術ビルダーがAIから実際の価値を得やすい領域の一つです—出力は通常人がレビューしてから送信されるからです。

すぐに作れるもの

実用的な「ドキュメントアシスタント」は雑多な入力を一貫した再利用可能なフォーマットに変換します。例えば：

• 非構造化メモを構造化レコードにする： コールメモや現地訪問のメモを貼り付けると、出席者、目標、決定、リスク、次のアクション、担当者といったクリーンなレコードを返す
• 週次ステータスレポートを生成： 複数人の箇条書き更新を投入すると標準化された報告書（進捗、障害、指標、依頼）を作る
• 幹部向けサマリーを一貫したフォーマットで作る： 毎回同じ見出しを持つ1ページを自動生成し、上級者がざっと目を通せる形にする

テンプレートで「ランダムさ」を減らす

助けになる報告と曖昧な報告の差はほとんどがテンプレートにあります。

スタイルルールの例：

• 常に見出しを使う：Summary、Highlights、Risks、Decisions Needed、Next Actions
• 要約は最大5文に収める
• 中立的な言葉を使い、推測は避ける
• 主張がある場合は入力のどの行に基づくかを引用する（引用または箇条の参照）

これらのルールを再利用可能なプロンプトとして保存するか、ラベル付きフィールドにユーザーが更新を貼るフォームを作ると良いです。

安全なケースとリスキーなケース

安全寄り： あなたが提供した情報（自分で書いた会議メモ、承認済みの指標、プロジェクト更新）から内部報告を下書きし、人が検証してから共有するケース。

リスク高め： 入力に明確にない数字や結論を生成するケース（部分的なデータから売上予測を出す、離脱率変化の理由を「説明する」、準拠文言を生成するなど）。これらは自信たっぷりに見えて誤りであることがあります。

外部へ共有する場合は必ず「出典チェック」を必須にし、機密データをプロンプトに入れないようにしてください（詳しくは /blog/data-privacy-for-ai-apps を参照）。

カテゴリ5：承認ワークフロー付きのコンテンツツール

コンテンツは非技術系AIアプリが活躍しやすい分野の一つです—人が介在できるため安全性が高く、目的は「自動公開」ではなく「下書きを早く作る／レビューを賢くする／一貫して公開する」ことです。

作れるもの（およびその理由）

短いブリーフ（対象、オファー、チャネル、トーン）から以下を生成できます：

• ソーシャル投稿の下書き、ブログのアウトライン、広告のバリエーション
• 製品説明、SEOスニペット（文字数、キーワード、読みやすさ、禁止ワードなどの制約付き）

出力は捨ててもよい試作品なので、気に入らなければ破棄して編集し、再試行できます。

ガードレール：ブランドボイスと禁止フレーズ

最も有用な改善は「より創造的にすること」ではなく「一貫性」を作ることです。

小さなブランドボイスチェックリスト（トーン、推奨語、禁止語、フォーマットルール）を作り、すべての下書きを“ボイスチェック”に通すと効果的です。また、コンプライアンスや法務上のための禁止フレーズフィルタを入れ、レビュー前に問題を検出・フラグ付けできます。

A/Bバージョニングと承認ワークフロー

承認ワークフローがあることでチームで実用になります。良い流れの例：

1. 1つのブリーフに対して3–5のバリアントを生成
2. ラベルを付けて保存（Version A/B/C、チャネル、日付）
3. 適切な承認者にルーティング（マーケティング責任者、プロダクト、法務）
4. 決定と編集を記録して、次回の下書きに反映

既にフォーム＋スプレッドシート＋Slack／メールを使っているなら、ツールを変えずにその周りにAIを組み込めることが多いです。

最重要ルール：検証できない断定を避ける

AIはライティングアシスタントとして扱い、事実ソースとは見なさないでください。アプリはハードな主張（「効果を保証」「医療・金融の約束」「具体的な統計」など）を含む場合、自動的に警告を出し、引用や手動確認を要求するべきです。

シンプルなテンプレートとして、すべての下書きに「検証すべき主張」欄を追加し、承認はその欄を埋めることを条件にするのが有効です。

カテゴリ6：社内ナレッジベースのQ&A

社内ナレッジベースのQ&Aは典型的な「ドキュメントに聞く」ユースケースです：従業員が英語で質問を入力すると、既存の社内資料から引っ張って説明を返します。

非技術系ビルダーにとって達成しやすいAIアプリの一つで、モデルに新しいポリシーを“考えさせる”のではなく、すでに書かれていることを“見つけて説明する”ことが目的です。

早く作れるもの

実用的な出発点は、選別したフォルダ（オンボーディング文書、SOP、価格ルール、HR FAQなど）上での内部検索です。

オンボーディングバディを作り、新入社員のよくある質問に答えたり、ドキュメントでカバーされていない場合は「誰に聞くべきか」を案内したりできます（例：「これは未記載です—給与に聞いてください」や「RevOpsのAlexに確認」）。

セールス支援も合います：通話メモや文字起こしをアップロードし、要約と提案フォローアップを出す。ただし、アシスタントに使った出典の引用（引用部分）を必須にして、どこから取ったか分かるようにしてください。

ナレッジの衛生（信頼性を支える部分）

有用なアシスタントと混乱を招くアシスタントの差は“衛生”です：

• 出典リンク：すべての回答に使用したドキュメントへのリンクを含める
• 更新日時：「最終更新」を表示し、情報が古くなっている可能性を示す
• 所有者：各ドキュメント領域に責任者／チームをタグ付けする

ツールが出典を引用できない場合、人は次第に信頼しなくなります。

検索型回答が有効な場合とそうでない場合

検索（retrieval）は、ドキュメントが明確で一貫して文書化されている場合にうまく働きます（ポリシー、手順、製品仕様、標準的な返信など）。

一方、人の頭の中にしかない「真実」やチャットに散らばる情報、日々変わる内容（例外的運用、未確定の戦略、センシティブな従業員問題）ではうまく機能しません。その場合、アプリは「わからない」と言ってエスカレーションする設計にしましょう—推測して答えさせないでください。

カテゴリ7：ビジネスオペレーションの補助（慎重にだが可能）

ビジネスオペレーション領域はAIが実際の時間を節約できる場所ですが、小さなミスが高額になり得る領域でもあります。最も安全な「オペスヘルパー」は最終決定を下さず、要約・分類・リスクの可視化を行い人が承認するパターンです。

価値が高くリスクが低いヘルパー

経費分類＋レシート注記（会計判断はしない）：レシートや取引メモを読み、カテゴリを提案し短い説明を下書きする（例：「クライアントとのランチ、参加者を含める」）。重要なのは提案を人が確認し、元帳に反映する前に確定することです。

基本的な分析支援（数値ではなく説明）：スプレッドシートから「何が上がった／下がったのか」「季節性」「どの仮定が変わったか」を平易な英語（日本語）で説明する。ここでも「正しい予測」を返すのではなく、パターンを説明するアナリスト補助として位置づけてください。

契約とコンプライアンス支援

契約レビュー補助（人のレビュー用にフラグを立てる）：自動更新、解約、責任制限、データ処理条項など、注意が必要な条項をハイライトし、レビュアー向けのチェックリストを生成します。絶対に「安全です」「署名して良いです」とは言わせないでください。UI上に「法的助言ではありません」という明示を入れてください。

コンプライアンスに適したパターン：

• マスキング／赤字化：モデルに送る前に個人データを削除する
• アクセス制御：誰が機密文書をアップロード／閲覧できるかを制限する
• ログ：誰がいつ何を聞き、アシスタントが何を返したかを記録する

境界を明確にする

「Draft」「Suggestion」「Needs approval」といった明確なラベルと短い免責文（「法務／財務の助言ではありません」）を使ってください。範囲を安全に保つ方法については /blog/ai-app-guardrails を参照してください。

非技術ユーザーがまだ作るべきでないもの（現時点）

AIはドラフト作成、要約、分類、チャットに優れていますが、信頼できる“真実の機械”ではありません。高リスクアクションをAIに全面的に任せるのは危険です。以下は、より深い専門知識、厳密な管理、明確なリスク対策が整うまで避けるべきプロジェクトです。

ハイリスクな助言や意思決定

医療診断、法的判断、安全に直結するガイダンスを提供するアプリは避けてください。たとえ回答が自信満々に聞こえても、微妙に誤っていることがあります。これらの領域ではAIは管理的補助（メモの要約など）に限定し、専門家へ確実に回す設計にしてください。

レビューなしの完全自律的アクション

「メールを送る」「返金を実行する」「顧客記録を変更する」「支払いをトリガーする」といった行為を人の承認なしに行うエージェントは避けてください。安全なパターンは：AIが提案 → 人がレビュー → システムが実行、です。

完全な事実の正確性が求められるもの

モデルが100%正しいと仮定するアプリを作らないでください（例：コンプライアンスチェック、財務報告でソースと一致させる必要がある処理、出典なしの即時ポリシー回答）。モデルは幻覚する（hallucinate）ことがあり、文脈を誤読したりエッジケースを見落としたりします。

許可と管理のない機密データ利用

明確な許可、保持ルール、アクセス制御がない状態で機密データを扱うシステムは避けてください。誰が何を、どのように見られるかを説明できないなら、一旦設計を止めて管理策を整えてください。

デモで動いたからといって信頼性ではない理由

デモはきれいな入力と最良のプロンプトで動きます。実際のユーザーは雑なテキスト、不完全な詳細、予期しない要求を送ってきます。出荷前に現実的な例で十分テストし、「わからない」と表示する挙動を定義し、レート制限、ロギング、レビューキューなどのガードレールを追加してください。

AIアプリを成功させる方法：範囲、テスト、ガードレール

多くのAIアプリが失敗する理由は同じです：やろうとすることが多すぎて曖昧さが大きい。最速で有用なものを作る道は、最初のバージョンを「非常に特定の仕事をする小さな従業員」に見立てることです。明確な入力フォームと厳格な出力ルールを持たせます。

1) 狭く始める—実例を集める

あなたが繰り返し行っているワークフロー（通話を要約する、返信を下書きする、リクエストを分類する）を1つ選び、10–20件の実例を集めてください。

これらの実例が「良い結果」の定義になり、欠損や雑な書き方、多重意図といったエッジケースを早期に露呈します。良い結果を例で説明できないなら、AIはそれを推定できません。

2) プロンプトをミニ仕様のように書く

良いプロンプトは「親切に振る舞え」よりも、「外注先が従うべき指示」に近い形で書きます：

• 役割＋タスク：AIが何をし、何をしないか
• 利用可能なソース：どの入力を使ってよいか（フォームフィールド、貼り付けテキスト、特定ドキュメント）
• 出力フォーマット：結果をどのような構造で返すか（箇条書き、JSON、表）

これによりAIの即興性が減り、メンテナンスが容易になります。

3) 検証を追加する（生のAI出力をそのまま信じない）

簡単なガードレールが信頼性を飛躍的に高めます：

• 必須フィールド（顧客名、製品、緊急度など）
• 長さチェック（冗長や欠落を防ぐため）
• 構造化出力（カテゴリ、タグ、固定セクション）

別のツールが出力を使う場合は、構造化フォーマットを優先し、フォーマットに合致しないものは拒否してください。

4) ベスト・ワースト・変なケースでテストする

出荷前に小さなテストセットを作ります：

• ベストケース：全ての詳細が揃ったきれいな入力
• ワーストケース：あいまいな入力、コンテキスト不足
• 変なケース：皮肉、複数依頼、矛盾する情報

プロンプト変更のたびに同じテストを実行して、改善が他を壊していないか確認します。

5) 監視と反復

毎週少量の出力をレビューする計画を立ててください。AIが躊躇する箇所、出典を作り出す箇所、誤分類する箇所を追跡します。小さな定期的な調整が大規模な書き直しよりも効果的です。

出力にラベルを付ける、必要な場合は人の承認手順を入れる、機密データをプロンプトに入れる前にツールのプライバシー設定と保持ルールを確認する、という境界を設けてください。

最初のAIアプリのためのステップバイステップ計画

小さく終えられるが、来週の時間を確実に節約できるものから始めてください—「ビジネスをAIに任せる」ような大きな目標ではなく、退屈なくらい確実な最初の一勝が望ましい：繰り返し可能、測定可能、元に戻しやすいこと。

1) ツールを選ぶ前に仕事を定義する

1文で書いてください：

「このアプリは [誰が] が [何のタスク] を [どの頻度で] 行えるようにし、その結果として [何を得るか]。」

成功指標を一つ追加します、例：

• 「下書き時間を30分→10分に短縮する」
• 「リクエストの80%を編集なしで正しいフォルダに振り分ける」

2) シンプルなインターフェースを選ぶ

最も軽い入り口を選んでください：

• フォーム（構造化リクエスト向け、整合性が高い）
• チャット（探索的Q&A向け、柔軟）
• スプレッドシート（一括作業向け、オペレーションチームに最適）

迷ったらフォームから始めると良いです—良い入力は巧妙なプロンプトよりも強力です。

プロジェクトがプロトタイプから発展していく可能性がある場合、後で進化できるプラットフォーム（例：Koder.ai のようにチャットで作りつつ実際のアプリとしてデプロイ／エクスポートできるもの）を検討してください。

3) ワークフローを決める：下書き／承認／助言のどれか

AIに何を許可するか明確にします：

• 下書きのみ： 人がコピー／編集して使うためのテキストを生成
• 承認→送信： 人が確認してからシステムが送信／更新する
• 助言のみ： 次の施策を提案するが実作業は行わない

最初は下書きのみか助言モードでリスクを抑えるのが無難です。

4) 既にある連携先を洗い出す

追加ソフトなしで繋げられるものをリストアップ：メール、カレンダー、共有ドライブ、CRM、ヘルプデスク。あなたの「アプリ」は薄いレイヤーであって、リクエストを下書き＋適切な宛先に変えるだけでも価値があります。

5) 安全なローンチを文書化する

パイロットグループ（3–10人）で試し、良い出力・悪い出力の例を集め、簡単なチェンジログ（「v1.1: トーンを明確化、必須フィールドを追加」）を作ります。フィードバックボタンを付け、誤っていた場合にユーザーが素早く修正できるルールを設けてください。

ガードレールとテストのチェックリストが欲しい場合は /blog/how-to-make-an-ai-app-succeed-scope-testing-guardrails を参照してください。