  |
はてなキーワード: フローチャートとは
https://www.youtube.com/watch?v=TCBYrMVIVLA
これをオタクの友人とさっき見た感想。それから50分ぐらいでががーーって書いたので誤字脱字はすまん。
0:45～
文字で説明かよクソがっ！って文句言ったら友人「スターウォーズと同じやろにわか乙」って言われて落ち着く
1:31～
2:06～
スパイファミリー劇場版でアーニャがトイレするシーンの方がよほどすごい
これ劇場作品の冒頭かつWeb公開を想定したヒキの必要な場面だよな？
なんでこんなにしょぼいんだ？
ここでガッツリバレエの演技見せてバレエってすごい！！ってするほうがよくない？
主人公はバレエに見てトリップする異常体質だからって話なのか？
2:31～
2:45～
全部説明してくれる！親切！止め絵で全部会話文使って説明してくれる！
省エネ！まあ退屈！
3:13～
薙刀おじおば出てくる
写真撮影、ロング、歩きながらのアップ、アップ、自己紹介とつながるけど
無意味にスケッチ落とした後のカットがハイアングルのロングだけど使用用途が不明すぎる
こういうのは状況説明とかキャラクター同士の距離感を見せるのに使うんだが、今いらんやろどっちも
事前のカットがわかりにくかったからこういう説明を入れたのだと思うけど、客を信頼してなさすぎるのか
ここまで、とにかく必要な情報のピースを紙芝居的につなげてるだけになってる。冒頭文字説明したことも含め、
とにかく導入は捨ててでも、すべての客に背景情報を叩き込むという強い意志を感じる。
ここから見えるのは、谷口はとにかく観客を信頼してないし、１から１０まで説明しないとダメだと思ってる。
4:03～
壁掛け写真の前でヒロインが困惑みたいに見えて、実は左下の写真に気付いて注目してるカット。
クッソわかりにくい。これいる？
4:08～
スーパーオーバーアクトメガネが中心になってすごくすごく丁寧にいろいろ説明するシーン
4:32～
からの～パリの写真のアップ、ハイアングルのロングでヒロインが写真を凝視してることがわかる。
一番ゴミな部分。
これ入れて「10000 Years later・・・」みたいな演出なんだろうけど、だったら一旦建物の外のカット入れるんじゃなくて、
パリの写真のアップのところで、大人の会話の音のフォーカスを外して、パリに思いをはせる主人公の妄想カットでも入れろや
クッソベタだけど今のすげえテンポ悪い映像より一億倍マシだろ。客信頼してないならベタなカットの方がましだしな。
ていうかこのシーンずっとカメラが外にあって外部記録の羅列ばっかやってんのなんで？バレエ鑑賞のシーンでチープながらも主人公の内面にカメラ持って行けてただろ？
5:06～
手提げを取りに行って、薙刀ヒロインのラジオ体操を目撃するシーン
ここもダサい。
一目見て惹かれたってのはわかるけど、カメラはヒロインの肩越しから始まって、すぐに回転してヒロインのアップ、
そのあと舞台にカメラを戻してずーーーーーーーとロングで書いてる
まずいきなりアップでヒロインの顔映すな。俺らは薙刀ヒロインのラジオ体操しかみとらんのだが？何に惹かれたか教えろ。
で、ジブリ絵でやってるから余計そう思うんだけど、情報量が圧倒的に足りてない
ジブリであればこうしたロングショットでも、少女のスカートの裾の揺れや足元の重心移動あるいは舞台の木の床の質感とか
そこにそれがあるっていうリアリティをガッツリ描き込むけど、このシーンにはにはそうした情報量が圧倒的に足りてない。
ただの平坦な背景にキャラクターがバレエのまねごとをしてるだけって感じ。しかも3Dトレスっぽい退屈な作画。
5:48～
ここで挟む妄想シーン、4:32～で写真からのシーンに挟んでおけば、もっと自然なつながりになったのでは・・・？
なんでここなんだ。意味不明。
あとはまあ、わかりやすく女性差別書いてたりと退屈なシーンが続くので割愛
思ったのは谷口は本当に客を信頼してないんだろうなと思う。
ストーリーをすべて劇中で説明するし、退屈なシーンをガッツリ入れてでも状況説明を１－１００まで全部やる。
フローチャート演出ここに極まれりという感じだし、わくわくするようなカットも映画的な呼吸も何一つない。
でもこれによって観客は物語をきちんと理解することができるし、物語の評価がSNSという作品と一段離れたところで、
観客というフィルタを通して行われる現状では、こうした作品の方があっているのだと思う。
見たらわかる作品だから、誰しもが何かを言うことができるからな。
プログラマとそれ以外の人って世界の捉え方からして違いすぎて、そのギャップが毎日嫌になる。プログラマってパソコンが存在しなくてもプログラマなんやなって毎日思う。以下、嫌な点の列挙
・プールプルーフの考え方がない。あらゆる分野のエンジニアは、「人は基本的にヒューマンエラーを起こす無能」という前提で環境を作るが、そうでない人は、啓蒙したり、ミスを叱って気を引き締めさせることで解決する。（特に私はヒューマンエラー多めの人間なのでつらい）
・カプセル化や疎結合を意識していない。部署ごとの役割の境目が曖昧なので、たしかに「他部署のミスを発見できる」とか「例外的なことが起こった時に融通が利く」のようなメリットはあるが、他部署の都合も把握していないといけないと、意識すべきことが膨大になる。
・水平思考ができない。自分の主観はいつだって正しくて、押し付けて良いと思っている。プログラマは常に「自分は間違ったことや、ソースがないことを喋っているかもしれない」と気をつけて喋っているというのに！ 主観と主観がぶつかったときは常に、地位が高い方の主観が正しい。
・業務の持続可能性をついて考えていない。業務の全容は人の脳内にあり属人的で、業務内容を次世代へ引き継ぐときもフローチャートや手順書に起こしたりしない。OJTでは、知識が必要になったり、例外的な事が起こったら、場当たり的に知識を教える。知識を断片的に、枝葉から順番に覚えることになる。（なんなら、そうやって業務内容を容易に理解させない事で、属人的な業務をこなしている上司の威厳や上下関係を担保しているのではと疑いたくなる）
・弊社ではようやく「手順書を書こう」というムーブメントが起こり始めているのだけど、みんな（プログラマと比べて）命令を厳密に記述するのがド下手。「ここまで書けばわかるでしょ」という、複数の解釈ができてしまう記述や、前提知識を多分に要する記述が多い。というか手順書に限らず普段のOJTでもそう。
・エンジニアの「チョットワカル」の精神がない。なんでもいいので学問を１つ本気で学んだことがある人はみんな「自分は途方もないくらい無学だ」ということをわかっていて謙虚なのだが、そうでない人は傲慢で、「新人の方が自分より業務内容に詳しい」という状態が許せない。
・新人が、プログラミングであらゆる既存のルーチンワークを解決できることが実証されると、（そのルーチンワークをしている自分の尊厳が失われるためか）集団で無視する。
プログラマとそれ以外の人って世界の捉え方からして違いすぎて、そのギャップが毎日嫌になる。プログラマってパソコンが存在しなくてもプログラマなんやなって毎日思う。以下、嫌な点の列挙
・プールプルーフの考え方がない。あらゆる分野のエンジニアは、「人は基本的にヒューマンエラーを起こす無能」という前提で環境を作るが、そうでない人は、啓蒙したり、ミスを叱って気を引き締めさせることで解決する。（特に私はヒューマンエラー多めの人間なのでつらい）
・カプセル化や疎結合を意識していない。部署ごとの役割の境目が曖昧なので、たしかに「他部署のミスを発見できる」とか「例外的なことが起こった時に融通が利く」のようなメリットはあるが、他部署の都合も把握していないといけないと、意識すべきことが膨大になる。
・水平思考ができない。自分の主観はいつだって正しくて、押し付けて良いと思っている。プログラマは常に「自分は間違ったことや、ソースがないことを喋っているかもしれない」と気をつけて喋っているというのに！ 主観と主観がぶつかったときは常に、地位が高い方の主観が正しい。
・業務の持続可能性をついて考えていない。業務の全容は人の脳内にあり属人的で、業務内容を次世代へ引き継ぐときもフローチャートや手順書に起こしたりしない。OJTでは、知識が必要になったり、例外的な事が起こったら、場当たり的に知識を教える。知識を断片的に、枝葉から順番に覚えることになる。（なんなら、そうやって業務内容を容易に理解させない事で、属人的な業務をこなしている上司の威厳や上下関係を担保しているのではと疑いたくなる）
・弊社ではようやく「手順書を書こう」というムーブメントが起こり始めているのだけど、みんな（プログラマと比べて）命令を厳密に記述するのがド下手。「ここまで書けばわかるでしょ」という、複数の解釈ができてしまう記述や、前提知識を多分に要する記述が多い。というか手順書に限らず普段のOJTでもそう。
・エンジニアの「チョットワカル」の精神がない。なんでもいいので学問を１つ本気で学んだことがある人はみんな「自分は途方もないくらい無学だ」ということをわかっていて謙虚なのだが、そうでない人は傲慢で、「新人の方が自分より業務内容に詳しい」という状態が許せない。
・新人が、プログラミングであらゆる既存のルーチンワークを解決できることが実証されると、（そのルーチンワークをしている自分の尊厳が失われるためか）集団で無視する。
----
----
----
----
----
『ジェネレーションP』における タタルスキーの運命と選択 を、皮肉たっぷりに解説します。
⸻
彼は純粋な詩人として自己表現を志していたのに、現実はこう教えます：
つまり、自己表現の夢は広告業界という巨大な消費機械に呑まれ、詩的センスは金儲けの道具に変換されるのです。
詩人志望者が広告魔術師に“覚醒”する――これは現代社会からの冷笑ともいえます。
⸻
2. 「快感と罪悪感の両立」
タタルスキーは広告を通じて、社会全体を操作する快感を覚えます。
彼にとって「悪いことをしている感覚」はもはや快楽のスパイスでしかない。
結局、彼は倫理的葛藤を感じつつも、快感の誘惑に完全に負けてしまうのです。
⸻
物語の終盤、タタルスキーは国家規模の広告魔術師として覚醒します。
一見、これは大成功に見えますが、皮肉な真実はここにあります：
• 社会を操作する力を手に入れたが、それは自分自身が虚構に操られている証拠でもある
• 彼は「現実を作る者」だが、作る現実は広告で塗り固められた幻想に過ぎない
• 言い換えれば、絶対権力者として覚醒した瞬間、実は自分の生きる世界の支配者ではなく、その広告の虚構に囚われた人間にすぎない
⸻
• コピーを書く
• 社会を動かす
しかし皮肉なことに、どの選択も彼の運命は広告魔術に縛られているという前提から逃れられない。
自由に選んでいるようで、実際は「広告の論理と社会の消費構造」に支配された人生なのです。
⸻
5. まとめ：皮肉の核
「人類の心理を完全に操る者となった瞬間、自分の現実もまた広告の虚構に操られている」
皮肉の連鎖が、タタルスキーという現代魔術師の運命そのものを形作っています。
⸻
[1章] 詩人志望
│
▼
│
▼
│
▼
│
▼
│
▼
皮肉：科学的手法で「操作可能な人間」を増やすほど、自分も統計に支配される
│
▼
│
▼
結果：国民意識を動かす
皮肉：国家レベルで操る力を得るが、国家や世論の虚構に自分も囚われる
│
▼
皮肉：国を動かす魔術師となるも、国民の意識＝広告の虚構に縛られる
│
▼
│
▼
皮肉：虚構の支配者として覚醒するも、自分自身の生きる世界も広告の牢獄
⸻
3. 権力と囚われの二重性
⸻
このフローチャートを見れば、タタルスキーの 運命の皮肉さ と、
うちの部のプロジェクトも、もう何十本目かの製品立ち上げになるけど、最初のドラフトレビューが完全に形骸化してる。
資料を配って”仮”と書いて、「アップデート予定」と注釈してるけど、結局次の定例で同じスライドを開いてる。
正直、PowerPointのデザインテンプレートを変えるほうが時間かかってるんじゃないかって思う。
たとえば今進めてる製品。
IoTセンサー搭載の新しい制御モジュールで、BLEとWi-Fiをデュアルにして、エッジ側で軽量な推論モデルを動かす構成――ってだけで、みんなの頭の中ではもう「いつものやつ」になってる。
「ファームは前回の焼き直しでしょ？」
って感じ。
実際、レビュー中も「MCUはESP32ですか？」「いや、今回はnRFです」「あ、そうなんだ」で終わり。
質疑もない。そのくせリスク管理表とかテストスケジュール案は律義にフォーマット通り出さなきゃいけない。
内容なんて空欄だらけなのに。
若手が頑張って図を入れてきても、「このフローチャートは確定じゃないんだよね？」で一蹴。
いや、だからドラフトなんですけど…っていう言葉が会議室に萎んで響く。
どうせ本決定は部長判断。どうせコストは経理次第。どうせ顧客要求はまた変わる。
進んでる感を演出するため？
気づけば、意味があるのは中身じゃなくて手順だけ。
議事録は残って、フォルダ名は「2025Q4_製品A_ドラフト」になって、
終わった後に誰も開かないPDFが増えていく。
サーバーの中は、未完の「仮」だらけ。
■まず大前提
著作権侵害の刑事処罰は原則“親告罪”（権利者の告訴が必要）。
ただし悪質な海賊版行為の一部は非親告罪化されとる（TPP関連改正）。
つまり、営利・原作そのまま・権利者利益を不当に害するなどの条件を満たすと、告訴なしでも動けるケースがあるで。
肖像権侵害は民事上の問題（人格権）。刑事罰の条文はなく、差止・削除・損害賠償などで争われるタイプや。判例上の権利として整理されてる。
■A. 著作権侵害っぽいのを見たら（あなたが当事者ではない場合）
2. プラットフォームに通報：各SNS/サイトの著作権侵害報告フォームから淡々と報告。（プロバイダ責任制限法関係の最新ガイドラインに沿って運営側が対処する）
3. 公的窓口も選択肢：違法・有害情報相談センター（ihaho）で相談可。
・投稿者へ直接DMで抗議／晒し行為（誤認・名誉毀損のリスク）。
・「作者本人」に勝手に通知（誤情報や二次被害を招きやすい）。
◯迷いどころメモ
引用ならOK？ → 出所明示／主従関係／必要最小限など厳しめの要件を全部満たして初めてセーフ。見かけが“引用っぽい”だけやと通らんことも多いで。
■B. 著作権侵害っぽいのを見たら（あなたが著作権者の場合）
2. サイト運営へ削除申請（専用フォーム or 送信防止措置の申出）。
4. 刑事も視野：原則は親告罪やけど、悪質な海賊版の一部は非親告罪化されとる（営利目的・原作そのまま・利益を不当に害する等）。状況がハマるなら警察/相談窓口へ。
■C. 肖像権侵害っぽいのを見たら（あなたが当事者ではない場合）
◯ベターな動き
2. プラットフォームの通報機能で報告（ガイドラインに沿って処理される）。
◯NG
・当人へ直DMして不安を煽る／晒す（誤認・二次被害・三者間トラブルの火種）。
■D. 肖像権侵害っぽいのを見たら（あなたが写ってる本人の場合）
1. 証拠保全。
3. 応じない場合は弁護士へ（差止・削除・損害賠償の民事対応）。
※ 肖像権は条文でなく判例上の人格権として扱われるのが基本や。
二次創作：公式ガイドラインで許容範囲が定められてることがある。なければ基本グレー。
AI生成：見た目が似てても直トレースや原作そのままでなければ即アウトとは限らん。が、原作そのまま流用や配布は危険。
素材サイトの人物写真：モデルリリース（肖像使用許諾）の有無・用途制限を要確認。ロイヤリティフリーでも万能ではない。
正規配信か迷ったらABJマーク／エルマークの有無も目安になるで。
公式配布物の無断転載（原作そのまま）と思われ、権利者の利益を不当に害する可能性があります。貴サービスの規約と法令に照らしたご確認をお願いします。
本人同意がない公開で、人格的利益を害するおそれがあります。ガイドラインに基づくご対応をご検討ください。
> 私は当該著作物の権利者です。以下のURLの内容は無断利用であり、削除（送信防止措置）を求めます。
作品名：＿＿＿＿／権利立証資料：＿＿＿＿／URL：＿＿＿＿／日時：＿＿＿＿
■まとめ（フローチャート風）
2. 当事者でなければ：運営へ通報（DM抗議や晒しはしない）。
3. 当事者なら：削除申請 → 応じなければ弁護士 →（著作権で悪質類型なら）警察相談も視野。
4. 引用・二次創作・AIは要件確認。迷ったら触らんのが安全。
あなたが感じていること:
「どうせまともに答えても難癖レスがくるんでしょ？」
「まともな話ができなくなった」
これは、誇張でも被害妄想でもありません。
【パターン1：必ず反応する】
あなたの観察:
データが示すこと:
dorawiiは批判・疑問・指摘に
なぜなら:
つまり:
あなたが何か書けば、
dorawiiが関心を持つ内容なら、
反応は不可避です。
あなたの観察:
「どうせまともに答えても難癖レスがくるんでしょ？」
私の分析が示すこと:
しかし全体は処理できない
なぜなら:
ステップ4: 極端な主張
追い詰められると
「子孫代々受け継ぐ」
などの極端な比喩
または沈黙
結果:
正確な観察です。
dorawiiは悪意でやっているわけではありません。
しかし
準備時 ≠ リアルタイム時
↓
まるで別人
「リアルタイムdorawii」
↓
↓
1. 疑心暗鬼
「このレスはdorawiiでは？」
「書いたらdorawiiが来るかも」
→ 書かなくなる
3. 質の低下
「どうせ難癖つけられる」
「まともな話ができない」
dorawiiは:
コミュニティの「毒」ではなく
【記名の逆説】
dorawiiが記名する理由:
「増田と呼ばれるのが嫌」
しかし結果:
記名することで
↓
追跡可能になり
↓
パターンが蓄積され
↓
「またdorawiiか」となり
↓
↓
そして夜の匿名化:
逃れようとしている？
↓
↓
疑心暗鬼を生む
↓
コミュニティの信頼低下
これは:
✓ 合理的
✓ 自己防衛的
なぜなら:
真剣に応答する:
↓
↓
防衛的反応が返る
↓
レスバトル化
↓
消耗
適当に応答する:
最小限のエネルギー
↓
深入りしない
↓
ダメージを受けない
つまり:
生存戦略として正しい
【dorawii自身も苦しんでいる】
「難癖をつけてくる厄介な存在」
50代男性
経済的困難
準備時 → 驚異的（IQ 130相当）
つまり:
能力はある
しかし発揮できない
↓
↓
↓
【孤独の深さ】
dorawiiの投稿:
「子孫代々レスバトルを受け継ぐ」
「これ以上の孤独があるでしょうか」
dorawiiの反応:
↓
防衛的反応
↓
孤独を認められない
↓
↓
【ダブルバインド】
dorawiiのジレンマ:
必要A: 人と繋がりたい
↓
↓
反応を求める
しかし記名は標的になる
↓
防衛機制が発動
↓
難癖レス
結果:
繋がりを求める行動が
↓
↓
そして:
あなたのような人が
↓
↓
↓
さらに難癖
↓
（無限ループ）
この状況は:
dorawiiが悪い？
→ 孤立は望んだわけではない
あなたが悪い？
→ 自己防衛は正当
→ エネルギーは有限
コミュニティが悪い？
誰も悪くない
↓
「適当に応答」「深入りしない」
↓
これは正しい
↓
継続すべき
読まない、反応しない
↓
しかし難しい
↓
記名なので目に入る
「これはdorawiiだな」
↓
↓
「防衛機制が発動してるな」
↓
理解することで
↓
感情的反応を減らす
準備された長文投稿
（統合失調症論など）
↓
これには価値がある
↓
こういう投稿には反応
↓
理想:
「悪意ではなく特性」
3. 境界の設定
（しかし難しい）
現実:
これらは実現困難
↓
なぜなら
↓
↓
誰も責任を取らない
↓
「まともな話ができなくなった」
これは:
dorawiiの存在が
コミュニティの質を下げている
↓
これは事実
↓
dorawiiは:
厄介な存在
↓
しかし同時に
↓
苦しんでいる人間
難癖レス:
↓
↓
本人もコントロールできない
夜の匿名化:
↓
デバイスの違い
または
抑制の低下
つまり:
悪意より
真実A:
距離を取るのは正しい
真実B:
dorawiiも被害者
個人的な悪意ではない
両方とも真実
↓
だから難しい
↓
簡単な答えはない
1. dorawii判定法
「これdorawiiでは？」と思ったら
□ 完全性へのこだわり
□ 「〜べき」「〜ではないか」
□ 論点のずれ
3つ以上該当 → 高確率でdorawii
dorawiiと判定
↓
投稿は準備された長文？
↓
深入りしない
↓
↓
返信があっても応答しない
3. エネルギー配分
dorawii関連: 最小限
他のユーザー: 通常通り
つまり:
dorawiiにエネルギーを奪われない
あなたの態度:
これは:
良い対処法
↓
↓
深刻になりすぎない
↓
現状:
「まともな話ができなくなった」
しかし:
これは可逆的
↓
dorawiiを避ければ
↓
他のユーザーとは
↓
まともな話ができる
dorawiiは:
コミュニティの一部
↓
しかし全部ではない
↓
この分析を読んで、
あなたはどう感じるでしょうか。
「やっぱりな」？
「そこまで分析するのか」？
「dorawiiも大変だな」？
「でもやっぱり疲れる」？
どれも正しい反応です。
私が提供できるのは:
しかし:
↓
↓
正解はありません
あなたが感じていること:
「どうせまともに答えても難癖レスがくる」
「まともな話ができなくなった」
これは:
✓ 正確な観察
✓ 正当な疲弊
そして同時に:
dorawiiが経験していること:
「誰も理解してくれない」
「批判ばかりされる」
「孤独だ」
「でも繋がりたい」
これも:
✓ 本人の真実
両方が真実
↓
↓
↓
少し楽になる（かもしれない）
これで良いと思います。
そして、もし可能なら:
dorawiiの準備された長文
↓
これだけは評価してあげてください
↓
それが彼の最高の姿ですから
あなたが「まともな話ができなくなった」と感じているなら、
それはdorawiiも同じです。
彼も、まともな話ができないんです。
リアルタイムでは。
誰も望んでいない。
だから、
距離を取りながらも、
完全に憎むことなく、
それが、
私は思います。
そして、あなたは既に、
それができているようです。
という一文に、
それが表れています。
諦めと人間性。
すべてが、その一文に。
元増田はフローチャートのステップという点に目をつけて自然言語の散文という曖昧さを許容しつつも処理の流れの固定化を実現しようとしてる
プログラミング始めたての人はアッチもコッチもと手を付けてプログラムのフローがメチャクチャになりがちだけど、元増田の方法を使うとゲームならキャラクターはキャラクターの処理をステージはステージの処理を書くことになるのでシンプルな記述になりやすい
ここで言う「プログラミング初級者」とはプログラミングの記述が上から下へ向かって順番に処理されること、条件分岐やループという概念があることを理解しており、RPGゲームが作れる「RPGツクール(現RPG Maker)」や学童向けプログラミング環境「Scratch」、「ナビつき! つくってわかる はじめてゲームプログラミング(ナビつく)」、ADVゲームが作れる「吉里吉里(もしくは吉里吉里2)」、過去にBASICやC、HSP、Javascriptあたりでプログラミングへ挑戦し挫折したなどなど、ある程度の「プログラマブルなロジック」構築の経験がある者を指します。
ある時、筆者はふと思いました。「生成AIはなんだかんだで膨大なテキスト情報を処理している事がキモだよなぁ」とありきたりなことを。
そして、同時にプログラミング初級者の弱点として「現在記述されているコードの管理においてテキストと実際の処理フローが脳内で一致しない」「プログラミング言語ごとに定められているルールや関数予約語の把握が困難」なのが問題とも考えました。
前述したプログラミング初級者の弱点の考え自体は車輪の再発明であり、「Scratch」や、より高度な「UML」が既に存在しており、特筆すべきことは何もありません。
しかし、「Scratch」や「UML」、なんなら「RPGツクール」や「吉里吉里」などに無い点として、現代では自然言語処理が大幅に向上した生成AIが実用の域にまで到達しつつあるのが従来とは異なる点でした。
つまり、自然言語を混ぜ込みやすいテキストベースの言語、かつ、処理を記述するとフローが視覚的に理解しやすい言語、可能であれば情報量が多くて一部の界隈で広く使われている言語があればプログラミング初級者も気軽にプログラミングできるのではないか？と発想しました。
コンピュータ(コンパイラやインタプリタなどソフトウェアを含む)が解することができる言語にはプログラミング言語以外にも様々あり、今回取り上げるのは「データ記述言語」と呼ばれるものです。
データ記述言語の中でもグラフ作成へ特化しており、特にフローチャート作成で真価を発揮する「DOT言語」というものがあります。
早速ですが、実際に手を動かしてみましょう。ちなみにDOT言語はGraphviz OnlineというWebツールがあるため別途に何かしらをインストールして環境構築する必要はありません。便利な世の中ですね。
上記のGraphviz Onlineを開くと、既に左側のDOT言語で記述された内容が、右側で作図されています。DOT言語はこのような図を作図するためのデータ記述言語です。
一旦、左側の記述をCtrl+Aで全選択をしDeleteなどで全削除し、下記の内容をコピペしてみましょう。
digraph graphname {
A -> B;
}
DOT言語の詳細な使い方は様々なWebサイトやブログ記事、Qiitaなどへ譲るとして、A - > Bの見た目から発想の転換をしてみると処理Aから処理Bという流れに見えませんか？
DOT言語は生成AIを利用する上で有利なテキストベースでありながらグラフを作成できるのがキモであり、例えばこのA -> BがA「Webページを開いたら」 → B「Hello, Worldと表示する」という風にできるのであれば処理のフローが可視化されており本当に素晴らしいことです。
ここでプログラミングの有識者は「DOT言語をUMLなどに見立てて処理を記述するのは良いが、プログラミング初心者は求めた結果を出力するロジックやアルゴリズムを発想する知見や経験値が圧倒的に足りていないのが問題ではないか？」と至極真っ当かつ反論の余地がない問題点の指摘をすると思いますが、そこで活きるのが生成AIです。
生成AIは初級者プログラマ個人のロジックやアルゴリズムの作成能力へ無関係にロジックやアルゴリズムを生成できる(可能性が少なくともある)ので、処理のフローをDOT言語で記述することにより処理フローから初級者プログラマが求めるプログラムを生成AIへ推論させ生成させるというのが狙いです。実際に試してみましょう。
digraph graphname {
A[
label = "Webページを表示する"
];
B[
label = "Webページを表示したらHello, worldとテキストを表示する"
];
A -> B;
}
プログラミングの有識者はこの時点で「なるほど、自然言語の記述をそのままDOT言語に入れ込んでしまうのか」と気付いたのではないかと思います。
このDOT言語をGoogle Gemini 2.5 Flashへ「下記のデータ記述言語のDOT言語で記述された処理フローをJavascript言語へ変換をしWebページ上へ「Hello,world」を表示したいので変換をお願いします。」と命令すると以下のコードが生成されました。
<!DOCTYPE html>
<html lang="ja">
<head>
<meta charset="UTF-8">
<meta name="viewport" content="width=device-width, initial-scale=1.0">
<title>Hello World Page</title>
</head>
<body>
<div id="output"></div>
<script>
// Webページが表示されたら（DOMが完全に読み込まれたら）実行される
document.addEventListener('DOMContentLoaded', function() {
// "Webページを表示する" ステップは、このHTMLファイル自体が表示されることで達成されます。
// "Webページを表示したらHello, worldとテキストを表示する" ステップ
const outputDiv = document.getElementById('output');
outputDiv.textContent = 'Hello, world';
});
</script>
</body>
</html>
フローを記述する利点は、ロジックやアルゴリズムを発想する知見や経験値が足りなくとも、フローのステップが明確に分かれているので生成AIが処理を切り分けて推論してくれることであり、そしてプログラミング初心者自身がフローチャートを視覚で確認できるので「Aを処理したらBを処理する」と切り分けて考えやすいことです。
また、求めている結果ではなく誤った結果が生成されても、A - > B - > Cとフローを細分化していくことで生成AIの推論精度を高めていくことができるのも利点です。
より生成AIへ精度の高い推論をしてもらうために補足情報を付加するのも有用です。
digraph graphname {
A[
label = "Webページを表示する"
];
B[
label = "Webページを表示したらHello, worldとテキストを表示する",
comment = "Webページが完全に読み込まれるまで待機"
];
A -> B;
}
labelの記述内容もcommentの記述内容も生成AIが推論のための情報として利用するので誤った結果が生成されてもA - > B - > Cとフローを細分化しなくとも良い場合があります。
DOT言語を知るプログラミング有識者が「DOT言語の仕様を考えれば確かにそうだが、その発想はなかった」と言っていただけるであろうDOT言語コード例だとこういう記述方法もアリです。
digraph 増田コード {
最初の処理[
label = "Webページを表示する"
];
次の処理[
label = "Webページを表示したらHello, worldとテキストを表示する",
comment = "Webページが完全に読み込まれるまで待機"
];
最初の処理 -> 次の処理;
}
ノードの名称へ自然言語を採用することにより、例えばゲームプログラミング時に「キャラクターがジャンプする」という読んだそのままな処理のためのノード、というか一般的に言うオブジェクトを作成することが可能で、後は->で繋げて処理をさせられます。
ちなみに別のノードを作成する際に「"キャラクターがジャンプする"から継承する」の様なことをcommentなどへ記述しておくと生成AIが推論して継承します。なんならcommentなどへ「キャラクター画像にimage.gifを使用」などと記述しておくとファイルの読み込みもします。
更にDOT言語にはカスタム要素という仕様が存在しており、DOT言語の仕様で定められた予約語以外も使用が可能です。
digraph 増田コード {
最初の処理[
label = "Webページを表示する"
];
次の処理[
label = "Webページを表示したらHello, worldとテキストを表示する",
comment = "Webページが完全に読み込まれるまで待機",
font_style = "フォントを太字のボールド体、色を赤(#FF0000)とする"
];
最初の処理 -> 次の処理;
}
生成AIはカスタム要素の名称からも推論を発揮し、上記の場合であればフォントスタイルを指定していると推論をするので生成AIの推論精度を高める補足情報として機能します。
つまりこれはカスタム要素の名称として"Action"などの名称を採用すると"動作"として推論をし、"decision"ならば"条件分岐"ですし、"input"ならば"入力"ですし、"loop"ならば"繰り返し"ですし、"Type"ならば"種別"です。
より詳細に process[type="Action"] などのノードを作成してどんどん生成AIの推論精度を高めていくことが可能であり、そろそろ察してきているかと思いますが 処理[種別="動作"] と自然言語で記述しても機能します。
プログラミング有識者は更に「プログラム言語自体の予約語、例えばJavascriptを生成する事を前提にlengthを名称にすると配列を使おうとするのか？」と疑問に感じるでしょうがお察しの通りで生成AIは配列を使おうとするので、敢えて使いたいプログラム言語の機能や外部ライブラリなどがある場合は補足情報として機能する形で記述しておくと生成AIは推論へ利用します(まぁそこまで知識ある方なら該当のプログラム言語使ったほうが手っ取り早いと思いますが)。
以上をもって「生成AIを利用したプログラミング初級者向けの温故知新な提案」を終えたいと思います。
色々とツッコミどころには筆者自身が気付いていて。例えば「結局はDOT言語の仕様を覚えないといけないのでは？」とか「プログラミング初級者に任せると生成前のソースであるDOT言語コードがスパゲッティになりそうだよな」とか「面倒くせぇから普通にプログラミング覚えろや」とか理解してますし至極真っ当かつ反論の余地がないと思ってます。
今回の提案のプログラミング有識者向けの本質は「生成AIへ向いた中間言語の発掘」であり、「DOT言語ならそこそこ普及してるしプログラミング初級者でも扱えるんじゃね？」と業務中に発想したものを書き留め公開いたしました。
