Domain Driven Ignition ―― 或いはAIに代筆してもらった記事が評された事を贅沢に貧相なオツムで思慮する

Last updated at 2025-09-12Posted at 2025-09-12

「noteに書くのが妥当な記事だ」
と思いながらも、キーキャップがまともについていない、自分が実装したErgoDashでUbuntu上のDOOM Emacsにorg-modeでわざわざ随筆している。
なお、筆者のnoteアカウントはこちら。

何があったのか

随筆開始時点（2025-09-12T16:51）で、次の記事が生成AIに代筆させた割には、奇妙と称したい伸び方をしてるし内容も筆者が前から生成AIを用いる際に思い抱いていた事を如実に記していた：

おかげで上記の記事の一つにコメントまで残してしまった始末だ。

それだけ、今の就労継続支援事業所を利用している分際でもなお、
「連中とVibesが合わねえ……」
と、社会順応にあたっては全く要らない憤りを抱いてる現状である。

ひいては、この憤りと躍起というVibeを、
「せっかくだ。プロレスで言うところの『ヒール』役にでもなったら、俺の自虐も活かせるってものだ」
というDriveに退化して、以降随筆する始末である。

言葉遣いにはもちろん気をつける（侮辱語を用いない。名誉毀損に配慮する）が、産まれた環境が「牛と野生動物と対峙する」のが日常の道東民の為、ふとした時に読者の皆々様に対して無礼な物言いをしてる可能性はある。

ご容赦いただければ本当は良いのだが、生粋のエンジニアなら黙ってQiitaに報告するのが良いかと存ずる。

いずれにせよこの後を読むなら、
「悪魔のZを生み出してしまった地獄のエンジンチューナ」や、
「運転免許証を取っていないはずの息子に峠向こうの旅館までクルマで豆腐の配達をさせるおじさん」
を気取った35歳のIT界の浪人が戯言を書いているという事を念頭に置きながら読んで頂きたい。

本題

読者の皆様の期待を裏切る様で申し訳ないが、以降は件の記事をべた褒めする。

なぜAIに代筆させた文書が筆者に響いたか

ドライビング・テクニックだろう。一貫したドライブをGPTモデルに課す、テクニック。

逆に筆者がこうやって随筆している様は、脳裏という霧の濃い田舎道を走っている様なラフなドライビングである。

その辺り、件の記事の著者である @makotosaekit 氏は首尾一貫しているのである。

ソフトウェアでも同じであろう。むしろ『ドメイン駆動設計・開発』という用語が提示された際にも、
「なんだ、普通にやってたわ。つか、単一責任原則とかGoFのデザインパターンとかでも似たことは言っていただろう」
という設計者（デザイナー）は居たと存ずる。過去や現存のソースコードに対しての改修の際を含めて実践したかどうかは問わないでおこう。
なので、元々コードベースのプログラミングをやってきていた人々からすると割と、
「何を今更当然の事を言ってるんだ？」
と思われる可能性はある。

件の記事はその、
「プログラマ・エンジニアには今更の事を愚直に、言語は自然言語に置き換えた」
と蔑んだ見方はできるが、入力したよりも多く、かつ即席で使えるスニペットも散りばめた情報を生成した実例である。

また、『テクニック』と称したが、おそらく筆者の様な偏屈な人間に読ませる程の文章を出せるプロンプト（指示文）を綴れる様に当人がなるまでそこそこ時間は掛かっただろう。
その命令文を綴れる様になるまでの技術習得時間や漁った文献の量は、10年近く前の筆者の様な、
「今後のSTEM教育とか鑑みたら、確かに『論理的』とは何ぞやって説明できないとアカンなあ」
程度の認識なら至れないと思慮する。

再度記すが、記事そのものが代筆させた事という事を鑑みるに、それは
実例なのだ。欲動（Drive）を一貫して生成AIに出力させた良いハック、あるいはテクニックを目の当たりにしたのだ、筆者は。

「論より実装」を地で行った件の記事のDrivingにより、筆者にはAIに代筆させた件の文書でも心に響いてしまった……というより感服、完敗したのである。

AIに委任してレビュー無しにした実例でもある

ここからは立ち位置を代え、しっかりとプロレスでのヒールの様な記事を書く。

せっかく論理式を書くならだ、論理記号で書いて欲しいところはあった¹：

# 前提 (Premise)
システム（AI）が受け取る、議論の出発点となる事実です。
 * 前提1: a は入力された記事である。
   * a \in A （aは記事の集合Aの要素である）
 * 前提2: 全ての記事 x は、ただ一つのテーマ Theme(x) を持つ。
   * \forall x \in A, \exists! t (Theme(x) = t)


# 定義 (Definition)
操作や概念を明確に定めます。
 * 定義1: Summarize_Expert(x) とは、記事 x を専門用語を含めて専門家向けに要約する操作（関数）である。
 * 定義2: Summarize_Beginner(x) とは、記事 x を平易な言葉で初心者向けに要約する操作（関数）である。
 * 定義3: Output(x) とは、記事 x に対して最終的に生成されるべき成果物（要約）である。


# 公理 (Axiom)
このシステム内で絶対的な真実として扱われる、議論の余地のないルール（AIへの指示の核）です。
 * 公理1: もし記事 a のテーマが「テクノロジー」であるならば、最終的な成果物は「専門家向けの要約」でなければならない。
   * 論理式:
       Theme(a) = \text{「テクノロジー」} \rightarrow Output(a) = \text{Summarize\_Expert}(a)

 * 公理2: もし記事 a のテーマが「経済」であるならば、最終的な成果物は「初心者向けの要約」でなければならない。
   * 論理式:
       Theme(a) = \text{「経済」} \rightarrow Output(a) = \text{Summarize\_Beginner}(a)

プロンプトは「お願い」ではなく「コード」。論理式を応用した「公理系」プロンプトエンジニアリングより

次の様に書くのが筆者の理想の空論述語論理式だった²：

# 前提 (Premise)
システム（AI）が受け取る、議論の出発点となる事実です。
 * 前提1: a は入力された記事である。
   * a ∈ A （aは記事の集合Aの要素である）
 * 前提2: 全ての記事 x は、ただ一つのテーマ Theme(x) を持つ。
   * ∀x Theme(x)⇒∃!t {x | t_1 ... t_n}


# 定義 (Definition)
操作や概念を明確に定めます。
 * 定義1: SummarizeExpert(x) とは、記事 x を専門用語を含めて専門家向けに要約する操作（関数）である。
 * 定義2: SummarizeBeginner(x) とは、記事 x を平易な言葉で初心者向けに要約する操作（関数）である。
 * 定義3: Output(x) とは、記事 x に対して最終的に生成されるべき成果物（要約）である。


# 公理 (Axiom)
このシステム内で絶対的な真実として扱われる、議論の余地のないルール（AIへの指示の核）です。
 * 公理1: もし記事 a のテーマが「テクノロジー」であるならば、最終的な成果物は「専門家向けの要約」でなければならない。
   * 論理式:
       Theme(a) ⇔「テクノロジー」⇒ Output(a) ⇔ SummarizeExpert(a)

 * 公理2: もし記事 a のテーマが「経済」であるならば、最終的な成果物は「初心者向けの要約」でなければならない。
   * 論理式:
       Theme(a) ⇔「経済」 ⇒ Output(a) ⇔ SummarizeBeginner(a)

しかし逆説で考えると、件の記事が想定している生成AIは文脈を理解して行頭や単語の頭文字さえも適切に解釈するのだろうし、とっくにどのWebサービス提供のAIモデルも文脈を読んで文法は無視するとは思う。

また無論だが、∀（全て）や∃（存在）とか∧（かつ）、∨（または）、とか∈（属する）と記号が混入すると、エンジニアでも辛い人は辛いのだろう。ましてや用いられている記号から察するに、数理論理学よりは集合論に寄せている内容にもうかがえる。用いている記号と用い方が既にドメイン（議論領域）を2つ跨いでる。

おわりに

とかく書いたが、計算機相手に一番通じる話の仕方は、もう数年は論理や議論領域（それこそ『ドメイン駆動』の "Domain"）、あるいはモデル理論的な話になってしまう節はある。
逆に、論理的（つまるところ論文や理科の実験シートの様な様式の文書ないし文章）に日本語が掛ければなんとかなるし、更に任意の軽量マークアップ言語がかければ込み入った話も書けるはずである。
その事実を再提示した makotosaekit 氏の記事に対する評価は、捉え方によっては適切なのかもしれない。

なお、今回の記事タイトルの『Domain Driven Ignition』の意図としては、
「自分が何について話したいのか（関心事・議論領域）を意識する事に着目しようよー」
と、某アーケードゲームの最新タイトルを模倣して組んだ。
「その割には随分書いてる内容が方々に散ってるぞ？」
と言われど……すまない、一旦これで出させてくれ。

つまるところ、件の記事とそれに対する評価は makotosaekit 氏の仮説と実証結果としてはかなり愉快な結果になったのかもしれない。
しかし結果だけで終わらせるのは筆者の雰囲気では納まりが悪いので、この様に考察記事を書いてQiitaという場に投げかけてみたい欲動に駆られ、人力文章生成したのである。

なお、このポエムを書き終えるまで2時間、セルフ査読で2時間掛かっている。

「さっさとAIに代筆させたら良いのに」
とは筆者自身も思うが、まず筆者のオツムが貧相なので一度最後まで書かないと、
「俺は結局何が言いたいんだっけ？」
となるし、その主張に対して筆者自身がしたコメントを引用するなら；

むしろ述語論理に特化した『Prolog』というプログラミング言語があったり、公理証明の支援に『Rocq（旧：Coq）』の環境を別途用意して、一旦自分の思慮・論拠・設計を生成AIに投げる前に精査する

件の記事への筆者のコメントより

という過程をも挟む愚行も噛ませた上で、生成AIWebサービスに委任するだろう。クレジットカードの発行も許されない不安定な収入状況なものですからな。ココ、笑いどころです。

誤解しないで頂きたいのは、 makotosaekit さんはAIを通してない文章では辛味のある発言してる印象なので、付き合いやすいエンジニアだと筆者は思いますよ？

下書きのEmacs上ではバックスラッシュ部分は記号に表示を書き換えられるのだが ↩
本来はもっと論理記号と集合論の記号に集約可能とは存じますが、筆者が薄学なので次が限界でした。 ↩

You get articles that match your needs
You can efficiently read back useful information
You can use dark theme

What you can do with signing up