Diagram Examples from Real Visitor Prompts

ユーザーサインアップのフロー：メール入力、メール確認、パスワード作成、オプションのプロフィール設定、ダッシュボード表示

ArduinoのPWM信号でサーボモーター制御

急変時の救急搬送フローチャート 救急搬送基準 ↓ 基準に該当 ↓ 医療の希望と搬送希望病院があるか確認 ↓ 訪問診療医へ連絡し、医療の希望内容と搬送希望病院について伝える (ご家族と相談して搬送するか決めることになる) ↓ 搬送するように医師から指示があったら ↓ ↓ 搬送希望病院がある場合 搬送希望病院ない場合 ↓ 医師に搬送希望病院(かかりつけ病院)を伝え医師から病院へ連絡してもらう ↓ ↓ 搬送先が決まったら再度連絡することを伝える 医師に連絡をとってもらっている間に１１９に連絡して救急要請 ↓ ↓ 救急要請 医師から連絡があり ↓ かかりつけ病院の受け入れ承諾を得ていたら診療情報提供書を送ってもらう ご家族に搬送先の病院が決まったら連絡するので病院へ向かっていただくように説明 ↓ ※医師から家族に病院へ向かうように説明がいっているかどうか医師に確認 ↓ 救急隊が到着したら搬送希望病院へ連絡をとってもらい 救急搬送してもらう ※家族の同乗か後追いでも家族が病院に来ないと受け入れてくれない病院もあるので、事前に医師とどのようにやりとりしているか確認してください。 救急隊が到着したら搬送先が決まるまでは同乗してもらうように 救急隊からお願いされるので、お客様と一緒に同乗するが、 搬送先が決まったら救急車から降りて、「病院までは職員は同乗しない」 ※看護サマリーは入院が決まったらFAXする。

S1 原子模型 《構造》 前提：ドルトンの原子説 ブドウパンモデル▶土星モデル▶ボーアモデル▶シュレーディンガーモデル ダイアグラムチャート

S1 原子模型 《構造》 前提：ドルトンの原子説 ブドウパンモデル▶土星モデル▶ラザフォーななドモデル▶ボーアモデル▶シュレーディンガーモデル ダイアグラムチャート

S1 原子模型 《構造》 前提：ドルトンの原子説 ブドウパンモデル▶土星モデル▶ラザフォードモデル▶ボーアモデル▶シュレーディンガーモデル ダイアグラムチャート

S1 原子模型 《構造》 前提：ドルトンの原子説 ブドウパンモデル▶土星モデル▶ラザフォードモデル▶ボーアモデル▶シュレーディンガーモデル ダイアグラムフローチャート

S1 原子模型 《構造》 前提：ドルトンの原子説 ブドウパンモデル▶土星モデル▶ラザフォードモデル▶ボーアモデル▶シュレーディンガーモデル マインドマップ

S1 原子模型 《構造》 前提：ドルトンの原子説 ブドウパンモデル▶土星モデル▶ラザフォードモデル▶ボーアモデル▶シュレーディンガーモデル 組織図

S1 原子模型 《構造》 前提：ドルトンの原子説 ブドウパンモデル▶土星モデル▶ラザフォードモデル▶ボーアモデル▶シュレーディンガーモデル フローチャート

ラダー回路：２４時間タイマーで電源をオンオフしてオンの状態でモーターとポンプが始動する センサーが反応するとモーターとポンプがオフになる

COVID-19変異株の進化：武漢株からアルファ株、デルタ株、オミクロン株まで

大型類人猿の系統樹：ヒト、チンパンジー、ボノボ、ゴリラ、オランウータンを含み、枝長とブートストラップ値を表示

34人のクラスの人物相関図を作ってください。 仲良い人は緑、苦手な人は赤、元恋人は紫、その他の関係は青で表示してください。 人物： 辻いつか、辻かずま、藤内ちひろ、戸田こうた、中川ゆうじ、中村わかな、藤田さわ、藤吉えな、松井たくろう、溝口よしゆき、森たつき、森田ひなこ、山路あいら、吉田りゅうせい、若松まなみ、角谷まほ、岡本にこ、池本そら、今木あやと、上田ゆき、及川がく、大森きほ、奥村あずさ、小野そうた、北野けいご、北村ななほ、久郷ゆうが、上月かりん、清水なお、白井いろは、鈴木あさひ、滝川はるき、滝本けんすけ、田中すい。 関係： 及川がくと北野けいごは仲良い。 及川がくと久郷ゆうがは仲良い。 北野けいごと久郷ゆうがは仲良い。 角谷まほと中村わかなは仲良い。 角谷まほと若松まなみは仲良い。 中村わかなと若松まなみは仲良い。 森田ひなこと山路あいらは仲良い。 大森きほと藤吉えなは仲良い。 辻いつかと白井いろはは仲良い。 辻いつかと藤内ちひろは仲良い。 藤内ちひろと白井いろはは仲良い。 上田ゆきと鈴木あさひと田中すいはよく一緒にいる。 池本そらは上田ゆきが苦手。 北野けいごと岡本にこはお互い苦手。 小野そうたと鈴木あさひは元交際。 上月かりんは3組の椋と過去に交際。 奥村あずさと山路あいらは仲良い。 奥村あずさと上月かりんは関係がある。 奥村あずさと北村ななほは関係がある。 奥村あずさと滝川はるきは関係がある。 奥村あずさと角谷まほは関係がある。 奥村あずさと及川がくは関係がある。 奥村あずさと吉田りゅうせいは関係がある。 小野そうたと滝川はるきは関係がある。 滝本けんすけと今木あやとは関係がある。 滝本けんすけと辻かずまは関係がある。 滝本けんすけと岡本にこは関係がある。 北野けいごと辻かずまは阪神タイガースの話をする。 藤田さわと清水なおは生徒会執行部仲間。

商社オンラインシステムの業務フローを、スイムレーン形式の業務フローチャートとして作成してください。 【レーン】 左から以下の5レーンにしてください。 1. 商社 2. 商社オンライン／担当者 3. システム 4. 受注データ・DB 5. ACOS 【基本の業務フロー】 商社 ↓ 商社オンラインへ受注データを送信 ↓ 商社オンラインで受注データを受信 ↓ 受信した受注データを都市別に振り分け ↓ 振分H/Dを作成 ↓ 受注データチェック ↓ チェック結果を判定 チェックOKの場合 ↓ 受注登録 ↓ 受注H/Dへ登録 チェックNGの場合 ↓ エラー・チェックリストを出力 ↓ 必要に応じて担当者が「手直し処理」を行う ↓ 再度チェック・登録 【登録後の処理】 受注H/Dに登録された受注に対して、必要に応じて以下の処理を行う。 ・受注修正 登録済み受注のヘッダ・明細などを修正する。 ・受注キャンセル 登録済み受注を取消する。 ・受注エントリー 受注情報の登録・修正・追加を行う。 既登録受注を受注番号で呼び出して修正・明細追加することができる。 ・受注スペック修正 登録済み受注の製品スペックを修正する。 生産計画済みの明細は修正できない。 ・受注行番分割 1つの受注明細を複数の行番に分割する。 数量や製品サイズ、計画対象区分などを設定する。 【補助処理】 受注処理の中で必要に応じて以下の処理を行う。 ・特殊サイズ引合判定 受注番号に紐づく特殊引合データを確認し、特殊サイズ引合に該当するか判定する。 ・生産制約判定 規格、板厚、長さ、定耳などから生産上の制約を判定する。 ・ロール予定日算出 納期、重量、生産枠などをもとにロール予定日・計算納期を算出する。 【マスタ関連】 以下は受注処理を支えるマスタ管理として、メインフローとは分けて配置する。 ・特殊スペック需要家マスタ 需要家、規格、品種、板厚、板巾などの条件と製品コードの対応を管理する。 ・スポット受注№ スポット受注№と製品コードの対応を管理する。 【図の作り方】 ・添付した参考画像と同じようなスイムレーン形式にする。 ・各レーンの上部に担当者・システム名を表示する。 ・処理は四角形の箱で表現する。 ・判断はひし形で表現する。 ・処理の順番は矢印でつなぐ。 ・チェック結果の「OK」「NG」は分岐として明確に表現する。 ・受注修正、受注キャンセル、受注スペック修正、受注行番分割、受注エントリーは、基本フローの途中に無理に入れず、「受注H/D登録後、必要に応じて行う処理」として分岐させる。 ・補助処理やマスタ管理は基本フローと区別して配置する。 ・文字は簡潔にし、1つの箱に長文を入れすぎない。 ・後から編集しやすい、一般的な業務フローチャート形式にする。 【重要】 「都市別振分」は仕様上、システム処理と考えられるが、現時点では自動処理であることを完全には確認できていないため、「システム処理（推測）」と分かるようにしてください。

本回路は、9 Vの直流電源に対して、固定抵抗 \(R_1=1\,\mathrm{k\Omega}\)、\(R_2=1\,\mathrm{k\Omega}\) および可変抵抗 \(R_L=0～10\,\mathrm{k\Omega}\) を接続した回路である。\(R_1\) の後で回路は \(R_2\) 側と \(R_L\) 側に分岐しており、\(R_2\) と \(R_L\) は並列に接続されている。 可変抵抗 \(R_L\) と直列に電流計Aを接続し、\(R_L\) に流れる電流 \(I_L\) を測定する。また、\(R_L\) と並列に電圧計Vを接続し、\(R_L\) の両端電圧 \(V_L\) を測定する。

!A*!B*!C*!D + C*D + A*B*!C*!D

以下の条件に従って、文化祭当日のスタッフ用「テロップ管理サイト（テロップの追加・編集・削除）」に関する運営スタッフ向けマニュアルのフローチャートを作成してください。 ## 【前提条件】 - **目的**: 文化祭の当日マニュアル、および企画団体の案内やお知らせなどを流す「テロップ管理サイト」を操作する運営スタッフ向けの手順整理。 - **対象読者**: 文化祭の運営スタッフ・実行委員。 - **システムの仕様・ルール**: 1. テロップ管理サイトを使用する。 2. テロップのテキスト中にスペースを入力することで、表示が2ページ目以上に渡る仕様になっている。 3. 登録済みのテロップは、一覧から個別編集または削除が可能。削除時には警告が表示されるが、許可して進める。 ## 【フローチャートに含める項目・流れ】 以下の3つの作業フロー（「①新規テロップの追加」「②テロップの編集」「③テロップの削除」）を必ず順序立てて、スタッフの実際の操作として組み込んでください： ### 【フロー①：新規テロップの追加】 1. テロップ管理サイトへのアクセスの有無 2. 「情報元の選択」の有無 3. 「追加する内容」の入力の有無 4. テロップ内に「スペースを入力しているか」の有無（※スペースを入れるとテロップ表示が2ページ目以上に渡る仕様の解説を含む） 5. 「スペースを空けて後ろに追記する」等の確定ボタンのタップの有無、および登録完了 ### 【フロー②：登録済みテロップの編集】 6. 「登録済みテロップ一覧（個別編集・削除）」の中の該当する企画団体の「編集」ボタンのタップの有無 7. 「変更後の内容の入力」の有無 8. 「この内容で更新する」ボタンのタップの有無、および更新完了 ### 【フロー③：登録済みテロップの削除】 9. 「登録済みテロップ一覧（個別編集・削除）」の中の該当する企画団体の「削除」ボタンのタップの有無 10. 削除時の「警告に対する許可」の有無、および削除完了 ## 【出力形式】 - システムのプログラム構造（If-Elseなど）ではなく、**「スタッフの実際の入力・選択操作」**と**「スペースによるページ送りの注意点」「削除時の警告の扱い」**が当日の現場で直感的にわかり、ミスなくスピーディーに運用できるように、MarkdownのテキストベースまたはMermaid形式で視覚的なフローチャートとして出力してください。

以下の条件に従って、文化祭当日のスタッフ用「呼び出し番号の登録・管理画面」に関する運営スタッフ向けマニュアルのフローチャートを作成してください。 ## 【前提条件】 - **目的**: 文化祭の当日マニュアル、および企画団体の運営スタッフ（実行委員や参加団体メンバー）が自身で呼び出し番号を管理・操作するための手順整理。 - **対象読者**: 企画団体の運営スタッフ。 - **システムの仕様・ルール**: 1. スタッフ用の「呼び出し番号登録サイト」を使用する。 2. テンキーを使って「新しい呼び出し番号の登録（呼び出し）」と「完了した番号の削除」を行う。 ## 【フローチャートに含める項目・流れ】 以下の2つの作業フロー（「①番号の呼び出し登録」と「②番号の削除」）を必ず順序立てて、スタッフの実際の操作として組み込んでください： ### 【フロー①：呼び出し番号の登録】 1. 呼び出し番号登録サイトへのアクセスの有無 2. 「自分の企画団体のテンキー入力・管理」のタップの有無 3. 呼び出しをする番号をテンキーで入力の有無 4. 「設定を反映させる」ボタンのタップの有無 5. 呼び出し対象としての番号反映・完了の有無 ### 【フロー②：呼び出し番号の削除】 6. 再度の「呼び出し番号登録サイトへのアクセス」の有無 7. 再度の「自分の企画団体のテンキー入力・管理」のタップの有無 8. 削除する（呼び出しが完了した）番号の入力の有無 9. 「設定を反映させる」ボタンのタップの有無 10. 番号リストからの削除・反映の有無 ## 【出力形式】 - システムのプログラム構造（If-Elseなど）ではなく、**「スタッフの実際のテンキー操作と画面確認の手順」**が当日の現場で直感的にわかり、ミスなくスピーディーに運用できるように、MarkdownのテキストベースまたはMermaid形式で視覚的なフローチャートとして出力してください。

以下の条件に従って、文化祭当日の「華泉祭総合サイト（呼び出し番号の通知登録・確認）」に関するお客様対応用マニュアル向けのフローチャートを作成してください。 ## 【前提条件】 - **目的**: 文化祭の当日マニュアル、およびお客様（一般来場者や参加者）を案内・対応するスタッフ向けの手順整理。 - **対象読者**: 一般来場者（お客様）と、それをサポートする実行委員などのスタッフ。 - **システムの仕様・ルール**: 1. 華泉祭総合サイトを使用する。 2. 自分の呼び出し番号を通知登録することで、その番号が呼び出し対象になった際に通知が届く仕組み。 3. 通知が届いた後は、不要になった呼び出し番号を右側の「×」ボタンで削除できる。 ## 【フローチャートに含める項目・流れ】 以下の手順と状態を必ず順序立てて、お客様の行動とスタッフの案内として組み込んでください： ### 【フェーズ1：通知の登録】 1. 華泉祭総合サイトへのアクセスの有無 2. 「呼び出し番号」タブのタップの有無 3. 購入した企画団体の呼び出し番号の欄への「通知登録する呼び出し番号の入力」の有無 4. 「登録」ボタンのタップの有無 5. 対象番号が呼ばれた際の「通知の有無（プッシュ通知や画面表示）」 ### 【フェーズ2：通知の確認と削除】 6. 再度の「華泉祭総合サイトへのアクセス」の有無（通知確認時） 7. 再度の「呼び出し番号」タブのタップの有無 8. 「通知があった呼び出し番号の表示」の有無 9. 通知があった呼び出し番号が表示されている場合の「右側の×ボタンのタップ」の有無 10. ×ボタンのタップ後の「通知（表示）の消去」の有無 ## 【出力形式】 - システムのプログラム構造（If-Elseなど）ではなく、**「お客様の実際の操作・確認行動」**と**「それに対するスタッフの声かけ・案内（番号の登録方法や、呼ばれたら×で消せることの説明）」**が現場で直感的にわかるように、MarkdownのテキストベースまたはMermaid形式で視覚的なフローチャートとして出力してください。

以下の条件に従って、文化祭当日の「グッドデザイン大賞投票」に関するお客様対応用マニュアル向けのフローチャートを作成してください。 ## 【前提条件】 - **目的**: 文化祭の当日マニュアル、およびお客様（一般来場者や参加者）を案内・対応するスタッフ向けの手順整理。 - **対象読者**: 一般来場者（お客様）と、それをサポートする実行委員などのスタッフ。 - **システムの仕様・ルール**: 1. グッドデザイン大賞投票用のWebサイトを使用する。 2. 投票する企画団体は**上限なし（複数の企画団体を選択可能）**とする。 3. 各企画団体につき投票できる数は**1〜3票**とする。 ## 【フローチャートに含める項目・流れ】 以下の4つの要素を必ず順序立てて、お客様の行動とスタッフの案内として組み込んでください： 1. グッドデザイン大賞投票用の「二次元バーコードの読み取り」の有無 2. 「投票する企画団体のタップ（選択）」の有無（上限なしで複数選択可能であることの案内） 3. 「票数（投票数）のタップ・入力」の有無（各企画団体につき1〜3票の範囲で割り振る操作） 4. 「投票を送信する」ボタンのタップの有無 ## 【出力形式】 - システムのプログラム構造（If-Elseなど）ではなく、**「お客様の実際の行動・操作」**と**「それに対するスタッフの声かけ・案内（複数の企画に投票できること、各企画には1〜3票まで入れられることの説明）」**が現場で直感的にわかるように、MarkdownのテキストベースまたはMermaid形式で視覚的なフローチャートとして出力してください。

以下の条件に従って、文化祭当日の「企画団体への入室手続き」に関するお客様対応用マニュアル向けのフローチャートを作成してください。 ## 【前提条件】 - **目的**: 文化祭の当日マニュアル、およびお客様（一般来場者や参加者）を案内・対応するスタッフ向けの手順整理。 - **対象読者**: 一般来場者（お客様）と、それをサポートする実行委員などのスタッフ。 - **システムの仕様・ルール**: 1. 入室専用のWebサイトを使用する。 2. 入室記録が完了した後は、ブラウザの「リロード（再読み込み）」や「戻る」ボタンの操作は禁止とする。 3. 「閉じる」ボタンを押すと警告が出るが、警告を無視してそのまま閉じても問題ない（エラー等ではない）。 ## 【フローチャートに含める項目・流れ】 以下の5つの要素を必ず順序立てて、お客様の行動とスタッフの案内として組み込んでください： 1. 二次元バーコードの読み取りの成功・失敗 2. 「入室する」ボタンのタップの有無 3. ブラウザアプリケーションの「リロードボタン」のタップの有無（禁止・スタッフの注意喚起） 4. ブラウザアプリケーションの「戻るボタン」のタップの有無（禁止・スタッフの注意喚起） 5. ブラウザアプリケーションのサイトを「閉じるボタン」のタップの有無（警告表示が出た場合のスタッフの安心案内） ## 【出力形式】 - システムのプログラム構造（If-Elseなど）ではなく、**「お客様の実際の行動・操作」**と**「それに対するスタッフの声かけ・案内（トラブル防止）」**が現場で直感的にわかるように、MarkdownのテキストベースまたはMermaid形式で視覚的なフローチャートとして出力してください。

以下の条件に従って、文化祭当日の「企画団体からの退室・評価手続き」に関するお客様対応用マニュアル向けのフローチャートを作成してください。 ## 【前提条件】 - **目的**: 文化祭のマニュアル、およびお客様（一般来場者や参加者）対応用スタッフが使用するマニュアル向けのフローチャート。 - **対象読者**: 文化祭の一般来場者、および案内をする実行委員などのスタッフ。 - **システムの仕様・ルール**: 1. 退室専用のWebサイトを使用する。 2. 退室記録が完了した後は、ブラウザの「リロード（再読み込み）」や「戻る」ボタンの操作は禁止とする。 3. 「閉じる」ボタンを押すと警告が出るが、その警告を無視して閉じても問題ない（エラー等ではない）。 4. 「いいね」のタップは必須（0〜3個の中から選択）。 ## 【フローチャートに含める要素・分岐の項目】 以下の7つのアクション・状態の有無や流れを必ず順序立てて組み込んでください： 1. 二次元バーコードの読み取りの成功・失敗 2. 「コメントする」または「コメントしない」ボタンのタップの有無 3. コメント内容の入力の有無（「コメントする」を選んだ場合） 4. 「いいね」の数のタップの有無（0〜3個の選択 / 必須項目） 5. ブラウザアプリケーションの「リロードボタン」のタップの有無（禁止動作とスタッフの対応） 6. ブラウザアプリケーションの「戻るボタン」のタップの有無（禁止動作とスタッフの対応） 7. ブラウザアプリケーションのサイトを「閉じるボタン」のタップの有無（警告表示への対応） ## 【出力形式】 - Markdownのテーブル、またはテキストベースの視覚的なフローチャート（またはMermaid形式）で出力してください。 - システムのプログラム構造ではなく、**「お客様の実際の入力・選択行動」**と**「それに対するスタッフの声かけ・案内（リロードや戻るの禁止、警告の無視など）」**が現場で直感的にわかるように記載してください。

バランスライン入力の、モノラル3ch、ステレオ2chの小型ミキサー 各チャンネルのボリュームは60mmストロークのフェーダ