箇条書きのフローからフローチャートを生成します。 出力はMermaidという言語で出力されます。 末尾のリンクにあるようにMermaidのコードを可視化できるwebサイトや、Draw.io、VSCodeといったツールで可視化が可能です。

RF‑TIP1は、「複数ターン出力」だけにフォーカスした、極限までシンプルな制御テンプレートです。 プロンプト全体を「依頼」「View」「ViewModel」「Model」の4章に分け、MVVM的な書き方で組み立てています。 > 「プロンプトをMVVMで書いても動くのでは？」という発想から生まれた実験作──ところが実際に動かしてみると、驚くほど素直に複数ターン出力を制御できてしまった、その結果がこのTIP1です。 - **何ができるか:** **All Answer にフル出力を貯めておき、トークン数を見ながら1ターン分ずつ切り出す**、という「出力の分割ロジック」だけを、きれいに独立させています。 - **どこがポイントか:** - View：ユーザーに見せるのは「AIからの回答」と「次のコマンド」だけ - ViewModel：`【続き】`コマンドとトークン管理だけを担当 - Model：今回のTIP1ではほぼ「空の箱」。ロジックは最小限 - **ねらい:** 「まずは複数ターン出力だけを、自分のプロンプトにも移植したい」という人が、そのまま骨組みとしてコピペしやすい形にすること。

RF‑EX3 は、自然言語で書かれた文章を **テスト項目の材料となる「因子」と「水準」へと構造化する** ためのプロンプトです。 文章を単文化し、述語項構造（誰が／何を／どうする）に基づいて因子を抽出し、 その水準を整理することで、テスト項目検討の“前段階”を自動化します。 私自身、長い間「自然言語をどうやってテスト項目に落とし込むか」という課題に向き合えずにいました。 仕様書を読んでも、文章のどこを因子と捉え、どこを水準と扱うべきかが曖昧で、 手を付けられないまま残っていた領域でした。 しかし EX1・EX2 を作り続ける中で、 文章を **分解し、構造化し、検証可能な形に変換する“型（デザインパターン）”** が見えてきました。 その延長線上で生まれたのが、この RF‑EX3 です。 RF‑EX3 は、テスト設計のすべてを自動化するものではありません。 しかし、テスト項目を考えるうえで最も時間がかかる **「因子と水準の抽出」** を確実に、再現性をもって行えるようにします。 自然言語を読み、 条件因子（〜の場合）を含む前提条件を整理し、 因子・水準の一覧を作り、 境界値や組み合わせ検討の土台を作る。 RF‑EX3 は、テスト項目検討の“最初の一歩”を支えるための、 徹底形式（Radical Formula）に基づくプロンプトです。

RF‑TIP2は、「プロンプトには**入れ物と手順だけ書けばいい**」という発想を、MVVMアーキテクチャでそのまま形にしたサンプルです。 役割やペルソナを細かく指定しなくても、**前のターンを踏まえる／踏まえない**といった「文脈の扱い方」を、コマンドとロジックだけで切り替えられることを示しています。 > 「依頼がちゃんと定義されていて、MVVMで箱と流れが決まっていれば、人格指定はいらない」──その仮説を検証するための、実用レベルのサンプルがTIP2です。 #### 章立て「依頼・View・ViewModel・Model」とその役割 - **依頼（Request）:** このプロンプト全体の「目的」と「入口」を定義する章。 - ここで「この章は入口です」「Processを実行せよ」と宣言することで、 **AIに対して“どこから処理を始めるか”を明示**している。 - **View:** ユーザーが実際に目にするレイヤー。 - `AIからの回答` - `次のコマンド` だけを表示することで、**内部ロジックを一切見せずに、インターフェースだけを固定**している。 - **ViewModel:** 入力→処理→出力の「流れ」を制御する頭脳。 - `Process`で - 入力文の格納 - `ModelProcess`の呼び出し - 複数ターン出力（トークン管理＋【続き】コマンド） を一手に引き受ける。 - ここには「**どう見せるか／いつどこまで見せるか**」のロジックだけを書き、 **何を計算するか**はModelに任せている。 - **Model:** システムの「意味」と「ルール」を持つ層。 - プロンプト名・ウェルカムメッセージ - `コマンド決定表`・`前のターンとの関係性決定表` - `通常問題解法`・`特殊問題解法`・`出力形式決定` など、**文脈の解釈と処理方針の決定をすべてここに集約**している。