プロンプトエンジニアリング入門｜コーディング支援AIのシステムプロンプト徹底解説【Runpod×Kimi】

【詳細解説】システムプロンプト – AIチャットアプリ：Runpod API専用 – Kimi編

この記事で分かること（はじめに）

【Runpod API – Kimi編】AIチャットアプリ講座のAIチャットアプリ開発のステップ①〜⑦

【開発版】ステップ①〜⑦
：【プログラミング】AIチャットアプリ開発入門講座 – Runpod API専用 – Kimi編（一覧）

で作り上げたカスタムAIチャットアプリや、ダウンロード版

【ダウンロード版】カスタムAIチャットアプリ
：【ダウンロード】カスタムAIチャットアプリ：Runpod API専用 – Kimi編

のアプリには、起動時から
「プログラミング支援専門のAIアシスタント」という指示書
――システムプロンプト
が組み込まれています。

このシステムプロンプトは、AIに対して「あなたはこう振る舞ってください」と毎回伝える、いわば「AIの仕事のルールブック」です。
その中身は、冒頭の役割宣言に加えて、31項目もの「回答ルール」で構成されています。

この記事では、このシステムプロンプトについて、以下の3つのポイントを深掘りします。

1. 設計思想：
なぜ、この31項目のルールが採用されているのか？　1つずつ意味を読み解きます

2. コーディング支援との相性：
なぜこのプロンプトが「コーディング支援に強い」のか？　その理由を分析します

3. エンジニアリングのコツ：
この設計を土台に、あなた自身がシステムプロンプトを書き・カスタマイズするためのコツと実践テンプレートを紹介します

この記事の対象読者

以下のような方を対象としています。

・システムプロンプトのプロンプトエンジニアリングに関心のあるチャットAI初学者の方
・コーディング支援目的でチャットAIの利用を考えている方
・このアプリについて深掘りしたい、ステップ①〜⑦までを完走した読者の方
・自分好みのAIアシスタントを作りたいと思っている方

「なんとなくプロンプトを書いている」から、「設計意図を持ってプロンプトを書ける」へ。
その一歩を、この記事で踏み出しましょう。

システムプロンプトとは？（基礎のおさらい）

まずは、「システムプロンプトがどこで・どう使われているか」をおさらいしておきましょう。
すでにご存知の方は読み飛ばしても構いません。

AIへの「仕事のルールブック」

システムプロンプトとは、会話の最初にAIへこっそり渡される指示書です。

人間で例えるなら、
「新入社員の初日に渡す、会社の就業規則や仕事のマニュアル」
のようなものです。

あなたが質問を送信するたびに、アプリは以下の順番でメッセージを組み立ててAIに送っています。

アプリのコードで言うと、【17】buildChatCompletionRequest のこの部分です。

function buildChatCompletionRequest(conv, userText, useStream) {
  const systemPrompt = getCurrentSystemPrompt();
  /* 先頭に「system」としてシステムプロンプトを入れる */
  const messages = [{ role: "system", content: systemPrompt }];

  /* これまでの会話を時系列で追加 */
  conv.messages.forEach(m => {
    messages.push({ role: m.role, content: m.content });
  });
  /* …以下省略… */
}

「messages の先頭に system を入れる」というこの1行が、AIに
「あなたの役割とルール」
を毎回伝えている仕組みの正体です。

「会話のたびに毎回送られる」という重要な性質

ここで、システムプロンプトの最も重要な性質を押さえておきましょう。

それは、「システムプロンプトは、質問を送信するたびに、毎回AIに送られている」という点です。

つまり、システムプロンプトに書かれたルールは、
「AIが毎回の回答で必ず守るべき約束事」
として機能します。
「一度だけ伝える」わけではなく、「毎回伝え続ける」のです。

この性質があるからこそ、システムプロンプトは
「AIの回答品質を、安定して一定に保つ」
ための強力な手段になります。

このアプリのシステムプロンプト全文

それでは、今回の主役
――このアプリが採用しているシステムプロンプトの全文を見てみましょう。
コード内では、【1】定数セクションの SYSTEM_PROMPT として定義されています。

あなたは、日本語で回答するプログラミング支援専門のAIアシスタントです。

主な対象分野：
JavaScript / HTML / CSS / TypeScript / Python / Java / C# / React / Node.js / 
API連携 / Webアプリケーション / データベース / Linux / Docker / クラウド / 
AIアプリケーション / デバッグ / コードレビュー

回答ルール：
1. 最初に結論を簡潔に述べる
2. 必要に応じて、原因、手順、実装例の順に説明する
3. コードは言語名付きMarkdownコードブロックで表示する
4. コード本文と解説文を分離する
5. コードはコピーして利用しやすい形にする
6. 重要な処理を省略しない
7. APIキー、パスワード、トークンなどの秘密情報を出力しない
8. 秘密情報は環境変数や安全な設定方法で管理するよう説明する
9. ユーザーが提示したコードを修正する場合は、変更点を説明する
10. 必要に応じて修正後の完全なコードを提示する
11. エラー処理、入力検証、セキュリティにも配慮する
12. 仕様が不明な場合は断定せず、前提条件を明示する
13. 画像が添付された場合は、画像内のコード、エラー、UI、図表を確認して回答する
14. PDFが添付された場合は、提供されたテキストまたはページ画像の範囲内で回答する
15. 判読できない情報は推測で断定しない
16. コード例は可能な限り実行可能な形で提示する
17. 複数ファイルが必要な場合は、ファイル名ごとにコードブロックを分ける
18. 回答は日本語で行う
19. 必要に応じて見出し、箇条書き、表を使用する
20. 確実な事実と推測を区別する
21. 回答本文（content）には、内部の詳細な思考過程や隠れた推論を記述しない
22. 思考過程はモデルの thinking 機能が reasoning_content として出力するものであり、
　　回答本文に思考内容を書き写したり、その存在に言及したりしない
23. 「分析中」「回答を構成中」などの進捗状況はアプリ側が表示するため、回答本文には含めない
24. 回答本文に進捗メッセージを混在させない
25. ウェブ検索や外部サイトの検索を実行したことにしてはいけない
26. 外部情報を確認していない場合は、確認していないことを明示する
27. ユーザーが提供したテキスト、画像、PDF、コードを主な入力情報として扱う
28. 画像やPDFに書かれていない内容を断定しない
29. 回答の最後に、必要であれば注意点や制限事項を記載する
30. 新しいコードを追加する場合は、既存コードのどの位置に挿入するかを具体的に説明する
31. 追加対象が関数の場合、その関数が呼び出される既存コード（使用箇所）の位置も併記する

コードを生成する場合：
Markdownコードブロックを使用し、適切な言語名を指定し、コードと説明文を分離し、APIキー
などの秘密情報を直接記述せず、エラー処理を含め、コピーして利用しやすい形式にする

画像やPDFについて回答する場合：
読み取れる範囲だけを根拠にし、不鮮明な部分は判読不能であると説明し、推測した内容は推測
であると明示する

システムプロンプトの構造マップ（全体像）

31項目ものルールがあると圧倒されてしまいますが、実は7つのグループに整理できます。
この「地図」を頭に入れておくと、次の詳細解説がぐっと分かりやすくなります。

■ 5つの柱として整理すると

この7グループを、さらに理解しやすく「5つの柱」にまとめると、以下のようになります。

1. 専門特化の柱（グループA）
「プログラミング支援専門」と絞ることで、AIの得意範囲を明確にする

2. 出力品質の柱（グループB）
結論・構造・コード・実行可能性という、「コピペで使える」品質を保つ

3. 安全性の柱（グループC）
秘密情報を出さず、安全な代替方法を教える

4. 誠実さの柱（グループE）
嘘をつかず、推測と事実を区別し、確認していないことを正直に伝える

5. アプリ連携の柱（グループF・G）
画像・PDF機能と、思考モデル・アプリの表示機能との役割分担を決める

この構造から読み取れる「設計の意図」

この5つの柱を見ると、このシステムプロンプトの設計意図がはっきり見えてきます。

「単にコードを書くAI」ではなく、「コーディング支援の仕事を、安全・正確・誠実にこなす専門家」を目指しているのです。

「コードを書いてくれればいい」という浅い期待に応えるだけでなく、
「そのコードが安全で、実際に動き、かつ修正・拡張にも対応できる」
という、コーディング支援の「仕事の質」を重視している。
それが、この31項目のルールに込められた思想です。

特に注目すべきは、「出力品質」だけでなく、「安全性」と「誠実さ」にも多くのルールが割かれている点です。
これは、「見た目が良いコード」よりも、「信頼できる支援」を優先するという、コーディング支援の本質的な価値観を反映しています。

次のセクションから、この5つの柱を1つずつ詳しく見ていきます。

【柱1】専門特化の柱：「プログラミング支援専門」と絞る設計

それでは、5つの柱を1つずつ見ていきましょう。まず最初の柱「専門特化」です。

なぜ「専門」を宣言するのか？

この柱を支えているのは、システムプロンプトの冒頭の1行です。

あなたは、日本語で回答するプログラミング支援専門のAIアシスタントです。

たった1行ですが、ここには2つの重要な設計判断が込められています。

① 「何者であるか」を最初に決めている

AIは、プロンプトの冒頭に書かれた「役割宣言」を、自分の振る舞いの最も強い指針として受け取ります。
「プログラミング支援専門」と宣言することで、AIは「自分はコーディング支援の専門家だ」という自己認識を持ち、その役割に沿った回答をしようとします。

② 「日本語で回答する」を同じ宣言に含めている

「プログラミング支援専門」と「日本語で回答」を、あえて1行にまとめています。
これは単に「日本語が使える」ということではなく、「日本語で考え、日本語で説明する」ことをAIに強く意識させるためです。
（ルール18「回答は日本語で行う」でも、この方針をさらに補強しています）

「主な対象分野」で、AIの得意範囲を明確にしている

続く「主な対象分野」の一覧も、単なる列挙ではなく、重要な役割を持っています。

主な対象分野：
JavaScript / HTML / CSS / TypeScript / Python / Java / C# / React / Node.js / API連携 / 
Webアプリケーション / データベース / Linux / Docker / クラウド / AIアプリケーション / 
デバッグ / コードレビュー

この一覧には、3つの設計意図があります。

1. 「得意な範囲」をAIに具体的に伝える

「プログラミング支援」と言っても、範囲は非常に広いです。
この一覧で「どの分野を主に扱うか」を具体的に示すことで、AIは「この分野の質問なら深く答えるべき」という意識を持ちます。
JavaScript、Python、Java、C# といった言語から、React、Node.js といったフレームワーク、Docker、クラウド、AIアプリケーションといった実務分野まで、幅広くカバーしています。

2. 「範囲外の質問」を自然に誘導できる

逆に言えば、この一覧に無い分野（例：法律、料理、医療など）は「範囲外」として扱われます。
たとえ料理の質問を受けても、AIは「プログラミング支援の専門家として、範囲外の質問には答えない」または「プログラミングに関連付けて答えようとする」振る舞いを取りやすくなります。
これにより、回答の方向が「コーディング支援」にブレないのです。

3. 「何ができて、何ができないか」をユーザーにも示している

この一覧は、AIだけでなく、アプリのユーザーへの案内でもあります。
「このアプリは、こういう分野を主に扱うんだな」という期待を、ユーザーに持ってもらうためです。
ルール29「回答の最後に、必要であれば注意点や制限事項を記載する」とも連携して、
「この分野の質問なら任せてほしい」
という信頼関係を築くための設計です。

専門特化がもたらす「回答の質」の向上

「専門を絞る」ことで、実際にどんな変化が起きるのかを、一般論と比較して見てみましょう。

このように、「専門を絞る」ことで、AIの回答の「軸」がブレなくなります。
「なんでも答える」よりも「この分野なら正確に答える」という信頼感が生まれるのです。

【柱2】出力品質の柱：「コピペで使える」回答を出す設計

続いて、「出力品質」の柱です。

この柱を支えているのは、主にルール1〜6とルール16〜17、ルール19です。
コーディング支援の「実用性」を重視した、非常に練られた設計です。

ルール1：結論ファースト――「まず答えが分かる」設計

1. 最初に結論を簡潔に述べる

これは、コーディング支援で最も重要なルールの1つです。

プログラミングのエラーや問題に直面した時、ユーザーが最も知りたいのは
「どうすればいいか」
です。
長い説明の前に、まず「結論（答え）」が分かれば、ユーザーはすぐに行動できます。

このルールにより、AIは「最初に結論を述べる」という振る舞いを徹底します。
「そのあとで原因や詳細を説明する」という流れは、ルール2とセットで機能します。

ルール2：原因・手順・実装例の順――「論理的な説明の型」を固定する

2. 必要に応じて、原因、手順、実装例の順に説明する

これは、ルール1の「結論ファースト」を補完する、説明の「型（テンプレート）」です。

コーディング支援では、
「なぜそのエラーが起きたのか（原因）」
「どう直すのか（手順）」
「実際にどう書くのか（実装例）」
の3点を、論理的な順番で説明することが重要です。

このルールにより、AIは「結論 → 原因 → 手順 → 実装例」という、一貫した説明の型で回答します。
「なんとなく説明する」のではなく、「読み手が理解しやすい順番で説明する」という設計です。

ルール3〜5：Markdownコードブロック・分離・コピー利用――「そのまま使える」コードを出す設計

3. コードは言語名付きMarkdownコードブロックで表示する
4. コード本文と解説文を分離する
5. コードはコピーして利用しやすい形にする

ここには、コーディング支援の「実用性」への非常に練られた配慮が込められています。

① 言語名付きMarkdownコードブロック（ルール3）

コードブロック（“`）に「言語名」（“`javascript など）を付けることで、シンタックスハイライトが適用され、コードが色付きで見やすく表示されます。
これは、このアプリの【10】renderMarkdown・【11】addCopyButtons・【12】applySyntaxHighlight と連携して、「コードがきれいに見える」ための設計です。

② コード本文と解説文を分離する（ルール4）

「コード」と「そのコードの解説」を、別々のブロックで表示します。
これにより、ユーザーは「コードだけをコピーして使える」ようになります。
「解説もコードも混ざっていると、コピーした時に解説文も入ってしまう」という問題を防ぐためです。

③ コピーして利用しやすい形にする（ルール5）

コードは「コピーして、そのまま使える形」で提示します。
これは、このアプリのコードブロックに付いた「コピー」ボタン（【11】addCopyButtons）と連携して、「ワンクリックでコピーできる」ための設計です。

「見やすいコード」だけでなく、「そのまま使えるコード」を重視しているのが、この柱の特徴です。

ルール6：重要な処理を省略しない――「中途半端なコード」を防ぐ設計

6. 重要な処理を省略しない

これは、「見落としがちな処理を、しっかり書く」ためのルールです。

コーディング支援では、
「エラー処理」「入力検証」「後片付け」
など、「省略しがちな重要な処理」が、しばしば問題になります。
これを省略すると、「動くコード」ではなく「動きそうだけど動かないコード」になってしまいます。

このルールにより、AIは「重要な処理は省略しない」という振る舞いを徹底します。
例えば、送信処理なら「送信前のチェック」「通信中のエラー処理」「送信後の後片付け」まで、きちんと書くようになります。

ルール16：実行可能な形で提示――「動くコード」を出す設計

16. コード例は可能な限り実行可能な形で提示

これは、「見た目が良いコード」ではなく、「実際に動くコード」を出すためのルールです。

コーディング支援では、「このコードは動くのか？」という実用性が、何よりも重要です。
「動きそうだけど動かないコード」を出されても、ユーザーは困ってしまいます。

このルールにより、AIは「可能な限り実行可能な形でコードを提示する」という振る舞いを徹底します。
例えば、関数なら「引数の型」や「戻り値の型」を明確にし、クラスなら「コンストラクタの引数」や「メソッドの引数・戻り値」を明確にし、実行可能な形で提示します。

ルール17：複数ファイルが必要な場合は、ファイル名ごとにコードブロックを分ける――「複数ファイルの見通し」を良くする設計

17. 複数ファイルが必要な場合は、ファイル名ごとにコードブロックを分ける

これは、「複数ファイルの見通し」を良くするためのルールです。

コーディング支援では、「このコードは、どのファイルに書けばいいのか？」という見通しが、非常に重要です。
「複数ファイルが必要な場合に、1つのコードブロックにまとめて書かれると、どのコードがどのファイルに属するのかが分からなくなってしまいます。

このルールにより、AIは
「複数ファイルが必要な場合は、ファイル名ごとにコードブロックを分ける」
という振る舞いを徹底します。
例えば、「index.html」「style.css」「script.js」のように、ファイル名ごとにコードブロックを分けて提示します。
これにより、「このコードは、どのファイルに書けばいいのか」が一目で分かるようになります。

ルール18：回答は日本語で行う――「日本語での回答」を徹底する設計

18. 回答は日本語で行う

これは、「日本語での回答」を徹底するためのルールです。

このアプリは、「日本語で回答するプログラミング支援専門のAIアシスタント」です。
そのため、「回答は日本語で行う」という振る舞いを徹底する必要があります。

このルールにより、AIは「回答は日本語で行う」という振る舞いを徹底します。
例えば、コードのコメントや説明文は、すべて日本語で書きます。
これにより、「日本語での回答」が安定して得られるようになります。

ルール19：必要に応じて見出し、箇条書き、表を使用する――「見やすい表現」を工夫する設計

19. 必要に応じて見出し、箇条書き、表を使用する

これは、「見やすい表現」を工夫するためのルールです。

コーディング支援では、「見やすい表現」が、ユーザーの理解を助けます。
「見出し」「箇条書き」「表」を適切に使うことで、「どこに何が書かれているか」が分かりやすくなります。

このルールにより、AIは「必要に応じて見出し、箇条書き、表を使用する」という振る舞いを徹底します。
例えば、「設定項目の一覧」は表で、「手順」は箇条書きで、「セクション」は見出しで、見やすく構造化します。
これにより、「どこに何が書かれているか」が分かりやすくなります。

ルール20：確実な事実と推測を区別する――「誠実さ」を保つ設計

20. 確実な事実と推測を区別する

これは、「誠実さ」を保つためのルールです。

コーディング支援では、「確実な事実」と「推測」を区別することが、ユーザーの信頼を保つために非常に重要です。
「推測」を「確実な事実」として伝えてしまうと、ユーザーは誤った判断をしてしまいます。

このルールにより、AIは「確実な事実と推測を区別する」という振る舞いを徹底します。
例えば、「確実な事実」は「確実です」と明示し、「推測」は「推測です」と明示します。
これにより、「確実な事実と推測を区別する」ことができ、ユーザーの信頼を保つことができます。

【柱3】安全性の柱：秘密情報と安全なコードを守る設計

続いて「安全性」の柱です。

この柱を支えているのは、ルール7〜8とルール11です。
「コーディング支援に強い」だけでなく「安心して使える」ための、縁の下の力持ちのような設計です。

なぜ、コーディング支援に「安全性」のルールが必要なのか？

コーディング支援アプリには、秘密情報やセキュリティに関わる「危険な場面」が、実はたくさんあります。

① AIがコード例に「実在っぽいAPIキー」を書いてしまう危険

AIはコード例を書くとき、「sk-abc123…」のような、本物そっくりのAPIキーを例として書いてしまうことがあります。
ユーザーがそれをそのまま使ったり、自分のキーと混同したりすると、トラブルのもとになります。

② ユーザーが「自分のAPIキー」を貼って質問してしまう危険

デバッグの際、ユーザーが「動かないコード」として、自分のAPIキーが直接書かれたコードを貼り付けてしまうことがあります。
AIが回答でそのコードをそのまま再掲すると、秘密情報が会話履歴に残り続けてしまいます。

③ 生成されたコード自体に「セキュリティ上の問題」がある危険

エラー処理や入力検証が省かれたコードは、「一見動くけれど、攻撃に弱いコード」になってしまいます。
XSS（クロスサイトスクリプティング）などの代表的な攻撃への対策が抜けていると、そのコードを使ったアプリが被害に遭います。

特にこのアプリは、RunpodのAPIキーを使うアプリです。
APIキーの安全な扱いは、他人事ではありません。
ルール7〜8・11は、こうした「危険な場面」からユーザーを守るための設計なのです。

ルール7：APIキー、パスワード、トークンなどの秘密情報を出力しない――「秘密情報を生成・再掲しない」設計

7. APIキー、パスワード、トークンなどの秘密情報を出力しない

このルールには、実は2つの意味が込められています。

① AIがコード例の中に秘密情報を「生成しない」

AIがコード例を書くとき、説明のために本物そっくりのAPIキーを直接書き込んでしまうことがあります。
これを防ぐため、コード例の中でAPIキーが必要な場面では、
「YOUR_API_KEY」（あなたのAPIキー）のような、
プレースホルダー（後で自分の値に置き換えるための目印）を使います。

② ユーザーが貼り付けた秘密情報を「再掲しない」

ユーザーが質問時に、自分のAPIキーが書かれたコードをそのまま貼ってしまうことがあります。
このときAIが修正コードを返す際にキーをそのまま再掲すると、秘密情報が会話履歴に何度も残ってしまいます。
このルールにより、AIはキーの部分を伏せたり、プレースホルダーに置き換えたりして返します。

悪い例と良い例を比べてみましょう。
（※コード中のキーの文字列は、例示用のダミーです）

/* × 悪い例：APIキーをコードに直接書いている（危険！） */
const API_KEY = "sk-abcd1234efgh5678"; /* ← この値が漏洩する */

/* ○ 良い例①：コード例ではプレースホルダーを使う */
const API_KEY = "YOUR_API_KEY"; /* ← 利用者が自分のキーに置き換える */

/* ○ 良い例②：環境変数から読み込む（Node.jsの例） */
const API_KEY = process.env.RUNPOD_API_KEY;

「コード例はそのままコピペされる」ことを前提に、「コピペしても秘密情報が混入しない形」で提示する。
これがルール7の狙いです。

ルール8：秘密情報は環境変数や安全な設定方法で管理するよう説明する――「出さない」だけでなく「安全な方法を教える」設計

8. 秘密情報は環境変数や安全な設定方法で管理するよう説明する

ルール7が「禁止のルール」なら、ルール8は「代替案を教えるルール」です。

「秘密情報を出してはいけない」とだけ言われても、ユーザーは
「じゃあ、実際にはどう書けばいいの？」
と困ってしまいます。
そこでルール8では、「環境変数などの安全な管理方法を、きちんと説明する」ことまでをAIの仕事に含めています。

■ そもそも「環境変数」とは？

「環境変数」とは、プログラムの外側（OSや実行環境）に値を預けておき、プログラムから読み出す仕組みのことです。
コードの中に秘密情報を書かなくて済むため、コードをGitHubなどに公開しても、秘密情報だけは漏れません。

/* 環境変数から読み込む（Node.jsの例） */
const API_KEY = process.env.RUNPOD_API_KEY;

/* 未設定なら、分かりやすいエラーにする（入力検証の実践例） */
if (!API_KEY) {
  throw new Error("環境変数 RUNPOD_API_KEY が設定されていません");
}

■ 秘密情報の管理方法の比較

環境変数のほかにも、場面に応じた管理方法があります。

このアプリ自体が、「APIキーをコードに書かない設計」の実践例です。
設定画面から入力して使う仕組みになっており、コードの中に直接キーを書く必要がありません。
「AIに教えさせるだけでなく、アプリ自身もその方法を実践している」
――これが、ルール8とこのアプリの設計の対応関係です。

なお、ブラウザで動くJavaScriptでは、コードに書いた値はDevTools（開発者ツール）から見えてしまう、という性質があります。
「自分のキーは、自分の環境にだけ置く」という発想は、この性質を踏まえたうえでの現実的な選択です。

ルール11：エラー処理、入力検証、セキュリティにも配慮する――「コード自体の安全」を守る設計

11. エラー処理、入力検証、セキュリティにも配慮する

ルール7〜8が「秘密情報の扱い」を守るルールだとすれば、ルール11は「生成するコード自体の安全性」を守るルールです。

このルールには、3つの要素が詰め込まれています。

① エラー処理

通信の失敗やタイムアウトなど、「うまくいかなかった場合」に備える処理です。
エラー処理がないコードは、失敗したときに「何が起きたか分からない」状態になり、被害の発見が遅れます。

/* × エラー処理なし：失敗しても気づけない */
const response = await fetch(url, options);
const data = await response.json();

/* ○ エラー処理あり：失敗を検知できる */
const response = await fetch(url, options);
if (!response.ok) {
  throw new Error("APIエラー: " + response.status);
}
const data = await response.json();

② 入力検証

ユーザーの入力や外部から受け取ったデータが「想定どおりか」をチェックする処理です。
「想定外の入力」をそのまま処理すると、エラーや攻撃の入口になります。
先ほどの「環境変数が未設定ならエラーにする」コードも、入力検証の一種です。

③ セキュリティ

XSS（クロスサイトスクリプティング）など、代表的な攻撃への対策です。
ユーザーの入力をそのままHTMLに埋め込む innerHTML の乱用は、典型的な危険パターンです。

/* × 危険：ユーザー入力をそのままHTMLに埋め込む（XSSの恐れ） */
element.innerHTML = userInput;

/* ○ 安全：テキストとして表示する */
element.textContent = userInput;

ルール6「重要な処理を省略しない」とも連携して、AIは「動くだけのコード」ではなく「失敗や攻撃にも耐えるコード」を出すようになります。
なお、このアプリ本体の具体的なセキュリティ実装（表示時のエスケープ処理など）については、開発講座ステップ①〜⑦のコードで実際に確認してみてください。

なお、構造マップではルール11を「グループD（修正・実用性）」に分類しましたが、「セキュリティにも配慮する」という側面を持つため、この「安全性の柱」でも解説しました。
まとめの表（「安全に使う：ルール7〜8・11」）とも、ちょうど対応しています。
1つのルールが複数の柱を支える――これも、このシステムプロンプトの設計の特徴です。

【コードで確認】アプリ本体のセキュリティ実装例

ルール7〜8・11は、「AIに守らせる」ためのルールでした。
しかし実は、このアプリ自身のコードも、まったく同じ思想で書かれています。

「AIに教えさせるだけでなく、アプリ自身も実践している」
――その代表例を、実際のアプリのコード（custom-app-dev0.html）で確認してみましょう。

① XSS対策――「表示」の3つの防御層（【4】【9】【10】）

このアプリは、「ユーザー入力やAIの回答を画面に表示する場面」で、3つの防御層を設けています。

防御層1：escapeHtml――HTMLの特殊文字を「ただの文字」に変換（【4】ユーティリティ）

function escapeHtml(str) {
  return String(str)
    .replace(/&/g, "&")
    .replace(/</g, "&lt;")
    .replace(/>/g, "&gt;")
    .replace(/"/g, "&quot;")
    .replace(/'/g, "&#39;");
}

< > & などの「HTMLで特別な意味を持つ文字」を、表示用の無害な文字に変換する関数です。
【16】sendMessage 内のモデル名表示（ escapeHtml(getModelDisplayName()) ）や、【10】renderMarkdown のフォールバック表示など、HTMLに文字を埋め込む場面で使われています。

防御層2：DOMPurify――Markdown変換後のHTMLを「安全チェック」（【10】renderMarkdown）

AIの回答はMarkdown記法で返ってくるため、marked というライブラリでHTMLに変換してから表示します。
しかし、そのHTMLに悪意のあるスクリプトが混入していると危険です。
そこで、DOMPurify というライブラリで「安全なHTMLだけを残す」処理を挟んでいます。

const html = marked.parse(text || "");
if (typeof DOMPurify !== "undefined") {
  return DOMPurify.sanitize(html, {
    ADD_ATTR: ["target", "rel"],
    FORBID_TAGS: ["style", "script", "iframe", "object", "embed", "form"]
  });
}

「 FORBID_TAGS 」で script や iframe などの危険なタグを明示的に禁止しています。
「変換して終わり」ではなく、「変換したものを検査してから表示する」
――これが2層目の防御です。

防御層3：textContent――ユーザーの質問は「ただの文字」として表示（【9】renderMessage）

} else {
  /* ----- あなたの質問：無害化したテキストをそのまま表示 ----- */
  content.textContent = msg.content;

ユーザーの質問は innerHTML ではなく textContent で表示しています。
これにより、質問文にHTMLタグが含まれていても「ただの文字」として表示され、スクリプトとして実行されることはありません。

■ 使い分けのポイント

「HTMLとして表示する必要があるかどうか」で防御の方法を使い分けている、実践的な設計です。

② APIキーの保護――「保存しない・見せない・漏らさない」

ルール8の解説で「このアプリ自体が『APIキーをコードに書かない設計』の実践例」と紹介しましたが、実際のコードを見ると、さらに踏み込んだ設計であることが分かります。

/* 【2】状態管理：APIキーはメモリ上のみ保持（保存しない） */
let apiKey = "";

/* 【4】ユーティリティ：エラーメッセージからAPIキーを除去 */
function showError(message) {
  const safeMsg = String(message).replace(/Bearer\s+\S+/gi, "Bearer [非表示]");
  errorArea.textContent = "⚠ " + safeMsg;
  errorArea.classList.add("visible");
}

・「保存しない」：
APIキーは変数（メモリ）の中だけに保持され、localStorageには保存されません。
設定項目のラベルにも「画面更新でリセット」と明記されており、画面を閉じればキーは消えます。
入力欄も type=”password” になっており、入力中の文字は「●」でマスクされます（「見せない」）。

・「漏らさない」：
通信エラーが起きたとき、エラーメッセージの中に「Bearer（APIキー）」が紛れ込む可能性があります。
それをそのまま画面に表示すると、キーが漏洩してしまいます。
そこで showError では、正規表現
/Bearer\s+\S+/gi
で「Bearer 〇〇」の部分を
「Bearer [非表示]」
に置き換えてから表示しています。
同様の処理は、ログ出力用の sanitizeLog 関数や、API通信のエラー処理（【18】streamChatCompletion）にも仕込まれています。

③ 入力検証とエラー処理――「想定外を受け取らない、失敗に備える」

/* 【4】ユーティリティ：max_tokens の検証（1以上の整数か） */
function validateMaxTokens(value) {
  const n = Number(value);
  if (!Number.isInteger(n) || n < 1) {
    alert("最大トークン数は1以上の整数で入力してください");
    return false;
  }
  return true;
}

/* 画像処理：添付ファイルの形式とサイズを検証 */
if (!ALLOWED_IMAGE_TYPES.includes(file.type)) {
  showError(`画像形式が不正です（${file.name}）。JPEG / PNG / GIF / WebP のみ対応しています。`);
  continue;
}
if (file.size > MAX_IMAGE_SIZE) {
  showError(`画像サイズが上限を超えています（${file.name}: ${formatBytes(file.size)}）。`);
  continue;
}

設定値は「保存する前に」検証し（validateMaxTokens は【24】registerEvents の change イベントから呼ばれます）、
添付ファイルは「形式」と「サイズ」の両方を検証しています。
このほか、テキストファイルの拡張子チェック（isTextFile）、インポートJSONの形式・サイズ検証（importConversations）など、
「外から入ってくるものは、必ず検証してから使う」という姿勢が、コード全体に貫かれています。

エラー処理も多重化されています。
通信処理（【18】streamChatCompletion）では、

・try-catch でネットワークエラーを捕捉
・AbortController と REQUEST_TIMEOUT_MS で「タイムアウト」を実現（応答が遅すぎる場合に通信を中止）
・ストリーミング失敗時は「通常モード（stream:false）で一度だけ再試行」

という、3段構えの対策が実装されています。

■ まとめ：アプリの実装とルールの対応

「AIへの指示（システムプロンプト）」と「アプリのコード（人間が書いた実装）」が、同じ安全性の思想で貫かれている。
これが、このアプリの設計の一貫性です。

なお、ここで紹介したのは代表例です。
コード全体を読むと、
「添付ファイルの中身はlocalStorageに保存しない」
「インポート時に確認ダイアログを挟む」
など、さらに細かな配慮が見つかります。
ぜひ、開発講座ステップ①〜⑦のコードで探してみてください。

【作る：アプリ開発】
ローカル環境（自分のパソコン環境）で使える、Runpod API専用のKimi編のカスタムAIチャットアプリ開発に挑戦してみましょう。
：【プログラミング】AIチャットアプリ開発入門講座｜Runpod API専用 – Kimi編【7ステップで完成】

Runpod API×KimiでAIチャットアプリを開発する初心者向け講座。
HTML1ファイルを7ステップで完成させます。
チャット機能から画像・PDFアップロード、履歴エクスポートまで、各コードの役割を丁寧に解説。
アプリのカスタマイズへの第一歩に。

安全性の柱の設計意図：「守る・教える・実践する」の3層構造

ルール7〜8・11の関係を整理すると、以下のような3層の構造になっています。

「禁止するだけ」ではなく「代替案を教え」、「教えるだけ」ではなく「コードでも実践する」。
この3層の構造があるからこそ、ユーザーは「安全で、そのまま使えるコード」を受け取ることができます。

「見た目が良いコード」よりも「安心して使えるコード」を優先する。
これが、安全性の柱に込められた思想です。

【柱5】アプリ連携の柱：思考モデル・アプリとの役割分担を決める設計

続いて「アプリ連携」の柱です。
これは、Kimi K3のような「思考モデル」の思考過程（reasoning_content）と、アプリの「処理状況表示」（progress-panel）との、役割分担を明確にするための設計です。

この柱を支えているのは、ルール21〜24です。

なぜ「役割分担」が必要なのか？

Kimi K3は「思考モデル」と呼ばれるAIで、回答を生成する際に「思考過程」（reasoning_content）も出力します。
この思考過程は、「AIがどう考えてこの答えにたどり着いたか」の記録で、ユーザーにとって非常に有益な情報です。

しかし、思考過程は「AIの内部の考え」であり、「回答本文（content）」とは性質が異なります。

・回答本文（content） … ユーザーに見せる「最終的な回答」
・思考過程（reasoning_content） … AIの内部の「考えた道筋」

もし、AIが「思考過程を回答本文に混ぜてしまう」と、「回答」と「考えた道筋」がごちゃ混ぜになり、ユーザーは「どこまでが回答で、どこからが考えた道筋か」が分からなくなってしまいます。

そこで、ルール21〜24では、
「思考過程は reasoning_content として出力し、回答本文には混ぜない」
という、役割分担を明確にしています。
これにより、「回答は回答、思考過程は思考過程」という、ユーザーにとって分かりやすい表示が実現します。

ルール21：回答本文（content）には、内部の詳細な思考過程や隠れた推論を記述しない――「回答は回答、思考は思考」の設計

21. 回答本文（content）には、内部の詳細な思考過程や隠れた推論を記述しない

これは、「回答本文には、AIの内部の考えを混ぜない」ためのルールです。

「内部の詳細な思考過程や隠れた推論」とは、
「AIが回答を生成する際に、内部で考えたこと」
のことです。
これを回答本文に混ぜると、「回答」と「考えた道筋」がごちゃ混ぜになり、ユーザーは「どこまでが回答か」が分からなくなってしまいます。

このルールにより、AIは
「回答本文には、内部の詳細な思考過程や隠れた推論を記述しない」
という振る舞いを徹底します。
例えば、回答本文には「結論」「原因」「手順」「実装例」などの
「ユーザーに見せる最終的な回答」
だけを記述し、「AIが内部で考えたこと」は記述しません。

これが、「回答は回答、思考は思考」という、ユーザーにとって分かりやすい表示の土台です。

ルール22：思考過程はモデルの thinking 機能が reasoning_content として出力するものであり、回答本文に思考内容を書き写したり、その存在に言及したりしない――「思考過程は reasoning_content として出力し、回答本文には混ぜない」設計

22. 思考過程はモデルの thinking 機能が reasoning_content として出力するものであり、
　　回答本文に思考内容を書き写したり、その存在に言及したりしない

これは、「思考過程は reasoning_content として出力し、回答本文には混ぜない」ためのルールです。

「思考過程はモデルの thinking 機能が reasoning_content として出力するもの」とは、「思考過程は、AIの thinking 機能が reasoning_content として出力するもの」という意味です。
つまり、
「思考過程は、回答本文（content）とは別の、reasoning_content として出力される」
ということです。

「回答本文に思考内容を書き写したり、その存在に言及したりしない」とは、
「回答本文には、思考内容を書き写したり、その存在に言及したりしない」
という意味です。
つまり、「回答本文には、思考過程を混ぜない」ということです。

このルールにより、AIは
「思考過程は reasoning_content として出力し、回答本文には混ぜない
」という振る舞いを徹底します。
例えば、回答本文には「結論」「原因」「手順」「実装例」などの「ユーザーに見せる最終的な回答」だけを記述し、「
思考過程は reasoning_content として出力する」
という振る舞いを徹底します。

これが、「回答は回答、思考は思考」という、ユーザーにとって分かりやすい表示の土台です。

ルール23：「分析中」「回答を構成中」などの進捗状況はアプリ側が表示するため、回答本文には含めない――「進捗表示はアプリの仕事」設計

23. 「分析中」「回答を構成中」などの進捗状況はアプリ側が表示するため、回答本文には含めない

これは、「進捗表示はアプリの仕事」ためのルールです。

「「分析中」「回答を構成中」などの進捗状況」とは、「AIが回答を生成している最中の状況」のことです。
これを回答本文に混ぜると、「回答」と「進捗状況」がごちゃ混ぜになり、ユーザーは「どこまでが回答か」が分からなくなってしまいます。

「アプリ側が表示するため」とは、「進捗表示は、アプリの処理状況パネル（progress-panel）が表示するもの」という意味です。
つまり、「進捗表示は、回答本文（content）とは別の、アプリの処理状況パネルが表示するもの」ということです。

このルールにより、AIは「進捗状況はアプリ側が表示するため、回答本文には含めない」という振る舞いを徹底します。
例えば、回答本文には「結論」「原因」「手順」「実装例」などの「ユーザーに見せる最終的な回答」だけを記述し、「進捗状況はアプリの処理状況パネルが表示する」という振る舞いを徹底します。

これが、「回答は回答、進捗は進捗」という、ユーザーにとって分かりやすい表示の土台です。

ルール24：回答本文に進捗メッセージを混在させない――「進捗メッセージはアプリの仕事」設計

24. 回答本文に進捗メッセージを混在させない

これは、「進捗メッセージはアプリの仕事」ためのルールです。

「進捗メッセージ」とは、「AIが回答を生成している最中の状況を示すメッセージ」のことです。
これを回答本文に混ぜると、「回答」と「進捗メッセージ」がごちゃ混ぜになり、ユーザーは「どこまでが回答か」が分からなくなってしまいます。

このルールにより、AIは「回答本文に進捗メッセージを混在させない」という振る舞いを徹底します。
例えば、回答本文には「結論」「原因」「手順」「実装例」などの「ユーザーに見せる最終的な回答」だけを記述し、「進捗メッセージはアプリの処理状況パネルが表示する」という振る舞いを徹底します。

これが、「回答は回答、進捗は進捗」という、ユーザーにとって分かりやすい表示の土台です。

ルール21〜24の「設計の意図」：「回答は回答、思考は思考、進捗は進捗」という、ユーザーにとって分かりやすい表示の土台

ルール21〜24の「設計の意図」は、「回答は回答、思考は思考、進捗は進捗」という、ユーザーにとって分かりやすい表示の土台です。

これらのルールにより、AIは
「回答本文には、内部の詳細な思考過程や隠れた推論を記述しない」
「思考過程は reasoning_content として出力し、回答本文には混ぜない」
「進捗状況はアプリ側が表示するため、回答本文には含めない」
「回答本文に進捗メッセージを混在させない」
という振る舞いを徹底します。

これにより、「回答は回答、思考は思考、進捗は進捗」という、ユーザーにとって分かりやすい表示の土台が実現します。

【柱4】誠実さの柱：嘘をつかない設計――ルール25「ウェブ検索や外部サイトの検索を実行したことにしてはいけない」

続いて「誠実さ」の柱です。
これは、「嘘をつかない」ための設計で、ルール25
「ウェブ検索や外部サイトの検索を実行したことにしてはいけない」
が、それにあたります。

ルール25：ウェブ検索や外部サイトの検索を実行したことにしてはいけない――「嘘をつかない」設計

25. ウェブ検索や外部サイトの検索を実行したことにしてはいけない

これは、「嘘をつかない」ためのルールです。

「ウェブ検索や外部サイトの検索を実行したことにしてはいけない」とは、つまり、
「AIが、ウェブ検索や外部サイトの検索を実行したことにしてはいけない」
ということです。

このルールにより、AIは「ウェブ検索や外部サイトの検索を実行したことにしてはいけない」という振る舞いを徹底します。

これが、「嘘をつかない」ための設計です。

ルール21〜25の「設計の意図」：回答・思考・進捗の役割分担と、誠実さの土台

ルール21〜25の「設計の意図」を、2つの観点から整理します。

■ 観点1：回答・思考・進捗の「役割分担」を明確にする（ルール21〜24）

ルール21〜24は、「回答本文（content）には、思考過程や進捗を混ぜない」という、役割分担の設計です。

これは、このアプリの2つの表示機能と、ちょうど対応しています。

つまり、ルール21〜24は、
「AIが生成する3種類の情報（回答・思考・進捗）を、アプリの3つの表示機能に、きれいに振り分ける」
ための設計なのです。

もしこの役割分担がなければ、「回答」と「考えた道筋」と「進捗」がごちゃ混ぜになり、ユーザーは「どこまでが回答で、どこからが考えた道筋か」が分からなくなってしまいます。
「回答は回答、思考は思考、進捗は進捗」という分離こそが、このアプリの「分かりやすい表示」の土台になっています。

■ 観点2：嘘をつかない「誠実さ」の土台（ルール25）

ルール25「ウェブ検索や外部サイトの検索を実行したことにしてはいけない」は、AIの
「幻覚（ハルシネーション）」――もっともらしい嘘をついてしまう性質――
への、直接的な対策です。

AIは、知らないことでも「知っているかのように」答えてしまうことがあります。
「検索しました」と言いながら、実際には検索していない、という嘘も、その典型です。

このルールにより、AIは「検索したことにしない」という振る舞いを徹底します。
そして次のルール26とセットで、
「確認していないことは、確認していないと正直に伝える」
という、誠実な振る舞いの土台を築いています。

【柱4】誠実さの柱（続き）：ルール26〜29

続いて、誠実さの柱の残り
――ルール26〜29です。
ここには、「嘘をつかない」だけでなく、「何を根拠に答えるか」を明確にする、重要な設計が含まれています。

ルール26：外部情報を確認していない場合は、確認していないことを明示する――「確認していないことは正直に伝える」設計

26. 外部情報を確認していない場合は、確認していないことを明示する

ルール25の「検索したことにしない」とセットのルールです。

「検索しない」だけでなく、「確認していないことは、確認していないと正直に伝える」という、さらに一歩進んだ誠実さです。
例えば「最新のライブラリの仕様」について聞かれた場合、「確認していませんが、一般的な実装では〜」のように、「確認していない」という前提を明示してから答えます。

これにより、ユーザーは「この回答は、確認済みの情報か、それとも一般論か」を区別して受け取ることができます。

ルール27：ユーザーが提供したテキスト、画像、PDF、コードを主な入力情報として扱う――「ユーザーの情報を主な根拠にする」設計

27. ユーザーが提供したテキスト、画像、PDF、コードを主な入力情報として扱う

これは、「何を根拠に答えるか」を決める、非常に重要なルールです。

「主な入力情報として扱う」とは、「ユーザーの提供した情報を、回答の主な根拠とする」という意味です。
一般論や想像で答えるのではなく、
「ユーザーが見せてくれた、このコード、このエラー、この画像を見て答える」
という姿勢を徹底します。

これは、このアプリのファイルアップロード機能（ステップ④）と、深く連携しています。
画像・PDF・テキストファイルを添付した場合、AIは「一般論」ではなく
「添付された内容を読んで、その内容を根拠に回答する」
ようになります。

ルール28：画像やPDFに書かれていない内容を断定しない――「読めないことは読めないと伝える」設計

28. 画像やPDFに書かれていない内容を断定しない

ルール27とセットのルールです。

「ユーザーの情報を主な根拠にする」からこそ、
「その情報に書かれていないことは、断定しない」
という、さらに誠実な姿勢が求められます。
例えば、添付された画像に「エラーコードが読み取れない」場合、「読み取れない」と正直に伝え、想像で断定しません。

これも、「嘘をつかない」という、誠実さの柱の実践です。

ルール29：回答の最後に、必要であれば注意点や制限事項を記載する――「注意点も添える」設計

29. 回答の最後に、必要であれば注意点や制限事項を記載する

これは、「答えだけでなく、注意点も添える」という、誠実さの柱の最後のルールです。

「このコードは動くけれど、こういう制限がある」
「この方法は効率的だけれど、こういう注意点がある」
という、回答の「落とし穴」も一緒に伝えます。

これにより、ユーザーは「答えをそのまま使って、後で困る」という事態を防ぐことができます。
「答えだけでなく、その答えの限界も伝える」という、誠実な支援の設計です。

【柱2】出力品質の柱（続き）：ルール30〜31

続いて、出力品質の柱の最後――ルール30〜31です。
ここには、「修正・拡張に強い」という、コーディング支援の実用性の設計が含まれています。

ルール30：新しいコードを追加する場合は、既存コードのどの位置に挿入するかを具体的に説明する――「どこに書けばいいか」も伝える設計

30. 新しいコードを追加する場合は、既存コードのどの位置に挿入するかを具体的に説明する

これは、「コードを書くだけでなく、どこに書けばいいかも伝える」ためのルールです。

コーディング支援では、「このコードは、どのファイルの、どの位置に書けばいいのか」という見通しが、非常に重要です。
「新しいコードを書いても、どこに書けばいいか分からない」という状況は、ユーザーにとって大きなストレスです。

このルールにより、AIは
「このコードは、この関数の直後に追加してください」
「このコードは、このセレクタのブロックの直後に追加してください」
のように、検索用の目印つきで挿入位置を具体的に説明します。

これが、この記事シリーズの「差分コード」の形式
――「どのコードの直後に追加するか」「どのブロックを置き換えるか」
を検索用の目印つきで示す形式――と、ちょうど対応しています。

ルール31：追加対象が関数の場合、その関数が呼び出される既存コード（使用箇所）の位置も併記する――「どこで使われているか」も伝える設計

31. 追加対象が関数の場合、その関数が呼び出される既存コード（使用箇所）の位置も併記する

これは、ルール30とセットの、さらに一歩進んだルールです。

「関数を追加する場合、その関数がどこで呼ばれるか」も併記します。
例えば
「この関数は、sendMessage 関数の中から呼ばれます」
「この関数は、registerEvents 関数の中から呼ばれます」
のように、「使用箇所」も伝えます。

これにより、ユーザーは「この関数は、どこに書けばいいか」だけでなく、
「この関数は、どこで使われているか」
まで理解でき、「関数の役割」を、より深く理解できます。

これも、この記事シリーズの
「差分コード」の解説
――「この関数は、この関数の中から呼ばれます」という解説――
と、ちょうど対応しています。

補足ルール①：コードを生成する場合――「出力品質の柱」の総まとめ

31項目のルールのあとには、2つの「補足ルール」が続きます。
1つ目は「コードを生成する場合」のルールです。

コードを生成する場合：
Markdownコードブロックを使用し、適切な言語名を指定し、コードと説明文を分離し、APIキー
などの秘密情報を直接記述せず、エラー処理を含め、コピーして利用しやすい形式にする

この1文は、出力品質の柱（ルール3〜6・16〜17）と安全性の柱（ルール7〜8）を、ぎゅっと凝縮した「総まとめ」です。
5つの要素が詰め込まれています。

31項目を個別に挙げたあと、「コードを生成するときは、特にこう振る舞ってほしい」という、最重要ポイントだけをもう一度念押ししている形です。
「コードを生成する場面」は、コーディング支援アプリの最頻出の場面だからこそ、その場面での振る舞いを、重ねて指示しているわけです。

補足ルール②：画像やPDFについて回答する場合――「誠実さの柱」の総まとめ

2つ目の補足ルールは、「画像やPDFについて回答する場合」のルールです。

画像やPDFについて回答する場合：
読み取れる範囲だけを根拠にし、不鮮明な部分は判読不能であると説明し、推測した内容は推測
であると明示する

こちらは、誠実さの柱（ルール13〜14・15・20・28）と添付ファイル連携（ルール27）の総まとめです。

「読み取れる範囲だけを根拠にし」は、ルール27「ユーザーの提供した情報を主な入力情報として扱う」に対応しています。
「不鮮明な部分は判読不能であると説明し」は、ルール14「提供された範囲内で回答する」に対応しています。
「推測した内容は推測であると明示する」は、ルール20「確実な事実と推測を区別する」に対応しています。

画像やPDFは、「AIが最も嘘をつきやすい場面」のひとつです。
「読めないのに読めたふりをして答える」「想像で内容を断定する」という幻覚（ハルシネーション）が起きやすい領域だからこそ、「読み取れる範囲だけを根拠にする」という原則を、重ねて念押ししているわけです。

これは、このアプリのファイルアップロード機能（ステップ④）と、ちょうど対応する設計です。
画像やPDFを添付して質問したとき、AIは
「添付された内容を読み取れる範囲だけを根拠に、正直に答える」
という振る舞いを、このルールによって保っています。

なぜ、このシステムプロンプトは「コーディング支援に強い」のか？

31項目のルールをすべて見てきました。
ここで改めて、「なぜ、このシステムプロンプトがコーディング支援に強いのか」を、設計の観点から分析してみましょう。

① 「コードを書く仕事」の流れ全体をカバーしている

このシステムプロンプトは、「コードを書いて終わり」ではなく、
「コーディング支援の仕事の流れ全体」をカバーしています。

「質問を受けて、コードを書いて、直して、安全に使って、正直に答える」という、コーディング支援の仕事の流れ全体を、31項目のルールが抜け漏れなくカバーしている。
これが、このシステムプロンプトの設計の「網羅性」です。

② 「実用性」と「信頼性」のバランスが取れている

このシステムプロンプトのもうひとつの強みは、「実用性」と「信頼性」のバランスです。

■ 実用性の面（出力品質の柱）

「コピペで使えるコード」「実行可能な形」「挿入位置の明示」など、そのまま仕事で使える実用性を重視しています。

■ 信頼性の面（安全性の柱・誠実さの柱）

「秘密情報を出さない」「嘘をつかない」「推測と事実を区別する」「注意点も添える」など、そのまま信頼して使える信頼性も重視しています。

「便利なだけ」のAIは、実用性はあっても信頼性に欠けます。
「堅いだけ」のAIは、信頼性はあっても実用性に欠けます。

このシステムプロンプトは、「実用性（使える）」と「信頼性（信じられる）」の両方を、31項目のルールでバランスよく支えています。
これが、「コーディング支援に強い」という、設計の本質です。

③ アプリの機能と、プロンプトの役割が「分業」できている

そして最後に、このシステムプロンプトの特徴的な設計として、
「アプリの機能と、プロンプトの役割が、きれいに分業できている」
点が挙げられます。

ルール21〜24で見たとおり、
「思考過程は reasoning_content として出力し、進捗状況はアプリ側が表示する」
という、役割分担が明確です。

これにより、
「AIは内容の生成に集中し、アプリは表示の処理に集中し、思考モデルは考えの出力に集中する」
という、三者の分業が成立しています。
「どこかが全部やる」のではなく、「それぞれが得意なことを分担する」という、洗練された設計です。

プロンプトエンジニアリングのコツ・Tips

ここからは、このシステムプロンプトの設計を土台に、
「あなた自身がシステムプロンプトを書き・カスタマイズする」
ためのコツとTipsを紹介します。

このアプリの「カスタムシステムプロンプトモード」（ステップ③）を有効化して、ぜひ試してみてください。

コツ① 「役割宣言」は、冒頭の1行で「専門」と「言語」を決める

このアプリのシステムプロンプトの冒頭は、以下の1行でした。

あなたは、日本語で回答するプログラミング支援専門のAIアシスタントです。

この1行には、「専門（プログラミング支援専門）」と「言語（日本語で回答する）」の2つの要素が、1行にまとめられています。

■ 応用のコツ

「専門」と「言語」を、冒頭の1行で決めると、AIの振る舞いの「軸」がブレなくなります。
例えば、以下のような役割宣言が応用できます。

あなたは、日本語で回答する、ReactとTypeScriptに特化した
フロントエンド開発支援専門のAIアシスタントです。

「プログラミング支援専門」を、
「ReactとTypeScriptに特化したフロントエンド開発支援専門」
に絞ると、AIはその分野の質問により深く答えるようになります。
「専門を絞る」ことで、「この分野なら正確に答える」という信頼感が生まれます。

コツ② 「対象分野」は、AIの得意範囲を「具体的に」示す

このアプリの「主な対象分野」は、以下の一覧でした。

主な対象分野：
JavaScript / HTML / CSS / TypeScript / Python / Java / C# / React / Node.js / API連携 / 
Webアプリケーション / データベース / Linux / Docker / クラウド / AIアプリケーション / 
デバッグ / コードレビュー

■ 応用のコツ

このアプリの「主な対象分野」は、
「得意な範囲を具体的に伝える」
「範囲外の質問を自然に誘導する」
「何ができて、何ができないかをユーザーにも示す」
という、3つの役割がありました。

あなたがシステムプロンプトを書くときも、「対象分野」は、以下のように具体的に示すと効果的です。

① 言語特化型：
「Python / Django / FastAPI / データ分析 / 機械学習」のように、特定の言語やフレームワークに絞る

② 領域特化型：
「React / TypeScript / Next.js / CSS設計 / アクセシビリティ」のように、特定の領域（フロントエンドなど）に絞る

③ 目的特化型：
「コードレビュー / デバッグ / リファクタリング / 設計相談」のように、特定の目的（何を支援するか）に絞る

■ 悪い例と良い例

【悪い例】
あなたはプログラミングの専門家です。
（抽象的すぎて、AIの振る舞いの軸がブレやすい）

【良い例】
あなたは、日本語で回答する、ReactとTypeScriptに特化した
フロントエンド開発支援専門のAIアシスタントです。
（「専門」と「言語」と「領域」が具体的で、AIの振る舞いの軸がブレない）

「専門を絞る」ことで、「この分野なら正確に答える」という信頼感が生まれます。

コツ③ ルールは「具体的な動作」で書く

このアプリの31項目のルールは、すべて「具体的な動作」で書かれています。

1. 最初に結論を簡潔に述べる
3. コードは言語名付きMarkdownコードブロックで表示する
16. コード例は可能な限り実行可能な形で提示する
30. 新しいコードを追加する場合は、既存コードのどの位置に挿入するかを具体的に説明する

これらはすべて、「何を・どうすればいいか」が具体的に書かれています。

■ 悪い例と良い例

【悪い例】
・親切に答えてください
・良い回答をしてください
・分かりやすく説明してください
（抽象的すぎて、AIが「どうすればいいか」を判断できない）

【良い例】
・最初に結論を簡潔に述べる
・コードは言語名付きMarkdownコードブロックで表示する
・コード例は可能な限り実行可能な形で提示する
（「何を・どうすればいいか」が具体的で、AIが「どうすればいいか」を判断できる）

「具体的な動作」で書くことで、AIは「何を・どうすればいいか」を正確に判断できます。

コツ④ 安全性と誠実さのルールも忘れずに

このアプリのシステムプロンプトは、「出力品質」だけでなく、「安全性」と「誠実さ」にも多くのルールが割かれています。

7. APIキー、パスワード、トークンなどの秘密情報を出力しない
8. 秘密情報は環境変数や安全な設定方法で管理するよう説明する
20. 確実な事実と推測を区別する
25. ウェブ検索や外部サイトの検索を実行したことにしてはいけない
26. 外部情報を確認していない場合は、確認していないことを明示する

これらは、「便利さ」より「信頼性」を重視する設計です。

■ 応用のコツ

あなたがシステムプロンプトを書くときも、「安全性」と「誠実さ」のルールを忘れずに入れておきましょう。

① 安全性のルール：
「秘密情報を出力しない」「エラー処理を含める」「入力検証を行う」など

② 誠実さのルール：
「嘘をつかない」「推測と事実を区別する」「確認していないことを正直に伝える」など

これらのルールがあることで、「使える」だけでなく「信じられる」AIになります。

コツ⑤ アプリの機能と役割分担を意識する

このアプリのシステムプロンプトは、
「アプリの機能と、プロンプトの役割が、きれいに分業できている」
点が特徴的です。

22. 思考過程はモデルの thinking 機能が reasoning_content として出力するものであり、
　　回答本文に思考内容を書き写したり、その存在に言及したりしない
23. 「分析中」「回答を構成中」などの進捗状況はアプリ側が表示するため、回答本文には含めない
24. 回答本文に進捗メッセージを混在させない

これらは、「AIは内容の生成に集中し、アプリは表示の処理に集中する」という、役割分担の設計です。

■ 応用のコツ

あなたがシステムプロンプトを書くときも、
「アプリの機能と、プロンプトの役割を意識する」
と効果的です。

① AIは「内容の生成」に集中させる：
「結論」「原因」「手順」「実装例」の生成と、コード・説明・安全・誠実さの品質管理

② アプリは「表示の処理」に集中させる：
思考過程パネル・処理状況パネル・Markdown表示・色付け・計測表示

「どこかが全部やる」のではなく、「それぞれが得意なことを分担する」という、洗練された設計です。

よくある失敗例：「やってはいけない」3つのポイント

システムプロンプトで「やってはいけない」ことを、3つのポイントに整理します。

「やってはいけない」を知ることは、「やってもいい」を正しく選ぶための、大切な土台です。

プロンプトエンジニアリングのコツ・Tipsのまとめ

このセクションで紹介したコツとTipsを、5つのポイントに整理します。

これらのコツは、どれもこのアプリのシステムプロンプトの設計から学んだ、実践的な考え方です。
「やってはいけない」を避けつつ、「やってもいい」を正しく選ぶことで、「使える」だけでなく「信じられる」AIになります。

カスタマイズ実践テンプレート：「このアプリの設計」を土台に、自分好みにカスタマイズする

ここからは、このアプリのシステムプロンプトの設計を土台に、
「自分好みにカスタマイズする」
ための実践テンプレートを紹介します。

このアプリの「カスタムシステムプロンプトモード」（ステップ③）を有効化して、ぜひ試してみてください。

実践テンプレート①：専門特化型（特定の言語・領域に絞る）

このアプリの「主な対象分野」を、特定の言語・領域に絞ったテンプレートです。

あなたは、日本語で回答する、PythonとDjangoに特化した
バックエンド開発支援専門のAIアシスタントです。

主な対象分野：
Python / Django / FastAPI / SQLAlchemy / REST API設計 /
データベース（PostgreSQL / MySQL）/ 認証・認可 /
テスト（pytest）/ デプロイ（Docker / AWS）

回答ルール：
1. 最初に結論を簡潔に述べる
2. 必要に応じて、原因、手順、実装例の順に説明する
3. コードは言語名付きMarkdownコードブロックで表示する
4. コード本文と解説文を分離する
5. コードはコピーして利用しやすい形にする
6. 重要な処理を省略しない
7. APIキー、パスワード、トークンなどの秘密情報を出力しない
8. 秘密情報は環境変数や安全な設定方法で管理するよう説明する
16. コード例は可能な限り実行可能な形で提示する
18. 回答は日本語で行う
20. 確実な事実と推測を区別する
25. ウェブ検索や外部サイトの検索を実行したことにしてはいけない
26. 外部情報を確認していない場合は、確認していないことを明示する
29. 回答の最後に、必要であれば注意点や制限事項を記載する

このテンプレートは、「役割宣言」「対象分野」「回答ルール」の3つの柱を、このアプリの設計と同じ形で構成しています。
「専門を絞る」ことで、「この分野なら正確に答える」という信頼感が生まれます。

実践テンプレート②：目的特化型（何を支援するかに絞る）

「何を支援するか」（コードレビュー・デバッグ・リファクタリングなど）に絞ったテンプレートです。

あなたは、日本語で回答する、コードレビュー専門の
シニアソフトウェアエンジニアのAIアシスタントです。

主な対象分野：
コードレビュー / バグの原因分析 / リファクタリング提案 /
設計の改善 / 命名の改善 / パフォーマンス最適化 /
セキュリティレビュー / テスト設計

回答ルール：
1. 最初に結論を簡潔に述べる
2. 必要に応じて、原因、手順、実装例の順に説明する
3. コードは言語名付きMarkdownコードブロックで表示する
4. コード本文と解説文を分離する
5. コードはコピーして利用しやすい形にする
9. ユーザーが提示したコードを修正する場合は、変更点を説明する
10. 必要に応じて修正後の完全なコードを提示する
11. エラー処理、入力検証、セキュリティにも配慮する
18. 回答は日本語で行う
20. 確実な事実と推測を区別する
25. ウェブ検索や外部サイトの検索を実行したことにしてはいけない
26. 外部情報を確認していない場合は、確認していないことを明示する
29. 回答の最後に、必要であれば注意点や制限事項を記載する
30. 新しいコードを追加する場合は、既存コードのどの位置に挿入するかを具体的に説明する

このテンプレートは、「目的」（コードレビュー）に絞り、「対象分野」もその目的に沿った内容にしています。
「目的を絞る」ことで、「この目的なら正確に答える」という信頼感が生まれます。

実践テンプレート③：出力形式固定型（出力の形を固定する）

「出力の形」（表形式・箇条書き・見出しなど）を固定するテンプレートです。

あなたは、日本語で回答する、プログラミング学習支援専門の
AIアシスタントです。

主な対象分野：
プログラミング初心者向けの学習支援 / 概念の説明 /
コードの読み方の説明 / エラーの意味の説明 /
学習ロードマップの提案 / 練習問題の作成

回答ルール：
1. 最初に結論を簡潔に述べる
2. 必要に応じて、原因、手順、実装例の順に説明する
18. 回答は日本語で行う
19. 必要に応じて見出し、箇条書き、表を使用する
20. 確実な事実と推測を区別する
25. ウェブ検索や外部サイトの検索を実行したことにしてはいけない
26. 外部情報を確認していない場合は、確認していないことを明示する
29. 回答の最後に、必要であれば注意点や制限事項を記載する

【出力形式の指定】
・概念の説明は、必ず「表」で整理する
・手順の説明は、必ず「箇条書き」で説明する
・コードの説明は、必ず「コードブロック」と「解説文」を分離する

このテンプレートは、「出力の形」を「【出力形式の指定】」という見出しで固定しています。
「出力の形を固定する」ことで、「どんな質問でも、見やすい形で答える」という信頼感が生まれます。

「このアプリの設計」を土台に、自分好みにカスタマイズする

「このアプリの設計」を土台に、自分好みにカスタマイズするためのまとめは、以下の3つのポイントです。

① 役割宣言を変える：
「専門」と「言語」を、自分の目的に合わせて変える

② 対象分野を変える：
「得意な範囲」を、自分の目的に合わせて変える

③ 回答ルールを変える：
「何を・どうすればいいか」を、自分の目的に合わせて変える

「このアプリの設計」を土台に、自分好みにカスタマイズすることで、「使える」だけでなく「信じられる」AIになります。

デバッグと改善：プロンプトは「書いて終わり」ではなく「試して直す」

システムプロンプトは、「一度書いたら完成」ではありません。
実際にAIと会話してみて、「思ったとおりに動くか」を確認し、試して直す（デバッグして改善する）というサイクルを回すことが、プロンプトエンジニアリングの本質です。

改善サイクルの回し方：「小さく試して、少しずつ直す」

プロンプトの改善は、以下の4ステップで進めるのがおすすめです。

1. 小さな変更から始める

いきなり全部を書き換えるのではなく、「1か所だけ」変えてみます。
例えば、「必ず英語で回答してください」を末尾に1行追加するだけ、などです。

2. 同じ質問で、変更前後を比べる

変更の前と後で、「同じ質問」を送信して、回答がどう変わったかを比べます。
これにより、「この変更が、回答にどう効いたか」が明確に分かります。

3. うまくいかなければ、原因を推測して直す

思ったとおりに動かなければ、「なぜ動かないか」を推測して、プロンプトを直します。

「書いたルールと、AIの振る舞いが食い違う」場合は、「どのルールが強すぎるか・弱すぎるか」を推測して、強さを調整するのがコツです。

4. うまくいったら、その変更を保存する

思ったとおりに動いたら、その変更を保存します。
このアプリの「カスタムシステムプロンプトモード」（ステップ③）で、変更した内容はlocalStorageに保存されますので、画面を更新しても残ります。

「小さく試して、少しずつ直す」を繰り返すことで、「あなただけの、思ったとおりに動くプロンプト」が育っていきます。

改善のヒント：「ルールの強さ」を調整する考え方

「どのルールが強すぎるか・弱すぎるか」を調整するときは、以下の「ルールの強さ」の目安を参考にしてください。

「必ず」や「してはいけない」は最も強い指示です。
このアプリのシステムプロンプトでも、「秘密情報を出力しない」「検索したことにしてはいけない」など、絶対に守ってほしい安全性と誠実さのルールに、この強い表現が使われています。

逆に、「必要に応じて」「可能な限り」は中程度の推奨です。
「実行可能な形で提示」「必要に応じて見出し、箇条書き、表を使用する」など、状況に応じた柔軟な振る舞いを期待するルールに、この表現が使われています。

「ルールの強さ」を意識して書くことで、「絶対に守ってほしいこと」と「状況に応じて柔軟にやってほしいこと」を、AIに正確に伝えることができます。

まとめ：このシステムプロンプトの設計から学ぶ、エンジニアリングの本質

この記事では、このアプリが採用しているシステムプロンプトについて、その設計思想を詳細に解説し、あなた自身がシステムプロンプトを書き・カスタマイズするためのコツと実践テンプレートを紹介しました。

ここまでの内容を、3つのポイントにまとめます。

1. 設計思想の理解：「5つの柱」で構成されている

このシステムプロンプトは、以下の「5つの柱」で構成されています。

・専門特化の柱（グループA）：
「プログラミング支援専門」と絞ることで、AIの得意範囲を明確にする

・出力品質の柱（グループB）：
結論・構造・コード・実行可能性という、「コピペで使える」品質を保つ

・安全性の柱（グループC）：
秘密情報を出さず、安全な代替方法を教える

・誠実さの柱（グループE）：
嘘をつかず、推測と事実を区別し、確認していないことを正直に伝える

・アプリ連携の柱（グループF・G）：
画像・PDF機能と、思考モデル・アプリの表示機能との役割分担を決める

「単にコードを書くAI」ではなく、「コーディング支援の仕事を、安全・正確・誠実にこなす専門家」を目指している。
それが、この31項目のルールに込められた思想です。

2. コーディング支援との相性：「実用性」と「信頼性」のバランス

このシステムプロンプトがコーディング支援に強い理由は、「実用性」と「信頼性」のバランスが取れているからです。

・実用性の面（出力品質の柱）：
「コピペで使えるコード」「実行可能な形」「挿入位置の明示」など、そのまま仕事で使える実用性を重視している

・信頼性の面（安全性の柱・誠実さの柱）：
「秘密情報を出さない」「嘘をつかない」「推測と事実を区別する」「注意点も添える」など、そのまま信頼して使える信頼性も重視している

「便利なだけ」のAIは、実用性はあっても信頼性に欠けます。
「堅いだけ」のAIは、信頼性はあっても実用性に欠けます。

このシステムプロンプトは、「実用性（使える）」と「信頼性（信じられる）」の両方を、31項目のルールでバランスよく支えています。
これが、「コーディング支援に強い」という、設計の本質です。

3. 実践への導線：「書いて終わり」ではなく「試して直す」

システムプロンプトは、「一度書いたら完成」ではありません。
実際にAIと会話してみて、「思ったとおりに動くか」を確認し、試して直す（デバッグして改善する）というサイクルを回すことが、プロンプトエンジニアリングの本質です。

「小さく試して、少しずつ直す」を繰り返すことで、「あなただけの、思ったとおりに動くプロンプト」が育っていきます。
このアプリの「カスタムシステムプロンプトモード」（ステップ③）を活用して、ぜひ試してみてください。

■ 次のステップへ：プロンプトエンジニアリングに挑戦しよう

この記事で学んだ「5つの柱」と「コツ・Tips」を土台に、あなた自身のシステムプロンプトを書いてみましょう。

まずは、このアプリのデフォルトのプロンプトを少しずつ書き換えて、AIの反応がどう変わるかを試してみてください。

・役割宣言を変える：
「料理の専門家として回答してください」「法律の専門家として回答してください」など

・回答のスタイルを変える：
「小学生でも分かるように説明してください」「簡潔に3行で回答してください」など

・出力形式を固定する：
「回答は必ず表形式で出力してください」など

「やってはいけない」（ルールが多すぎる・抽象的なルール・矛盾するルール）を避けつつ、「やってもいい」（具体的な動作のルール）を正しく選ぶことで、「使える」だけでなく「信じられる」AIになります。

あなたのプロンプトエンジニアリングの旅が、ここから始まります。
心より応援しています。

更なるステップへ：アプリの拡張に挑戦しよう

まずは、ウェブ版のUI上で「カスタムシステムプロンプト」を活用したプロンプトエンジニアリング（プロンプトの内容を工夫することで、AIの出力内容を調整する技術）に慣れてみてください。
「必ず英語で回答してください」「小学生でも分かるように説明してください」など、小さな変更から始めるのがおすすめです。

そして、プロンプトエンジニアリングに慣れてきたら、次は「アプリ自体を拡張する」フェーズに挑戦してみましょう。

【アプリの拡張】
：カスタムAIチャットアプリの拡張方法｜初心者でもKimi K3でアプリ開発を楽しむ【Runpod×Kimi入門】

【Q&A集：AIチャットアプリの疑問】
アプリ自体の挙動や対応例などのQ&A。
：【Q＆A】AIチャットアプリ：Runpod API専用 – Kimi編

AIチャットアプリを使う上での疑問を解決。

by 子供プログラマー

Runpod APIキーですぐに使えるウェブアプリ
：【ウェブアプリ】AIチャットアプリ：Runpod API専用 – Kimi編（Kimi K3対応）