  |
はてなキーワード:フローとは
現代日本における中国人観光客および外国人労働者のメディカルリソースへのフリーライド問題は、単なる社会保障財政のマクロ経済的インパクトを超え、公共経済学における情報の非対称性（インフォメーション・アシンメトリー）、プリンシパル・エージェント問題、アドバース・セレクション、モラルハザード、及び動学的最適制約（ダイナミック・オプティマリティ・コンストレイント）下でのポリシー・タイムインコンシステンシーを含む多層的システムリスクである。
岩屋大臣によるビザ緩和政策（デラテラリゼーション）は、ヒューマンキャピタルのトランスファビリティ及び労働市場のインピーダンスミスマッチ是正を目指したレギュラトリー・リフォームであり、短期的には潜在GDPのポジティブショック及びトータルファクター・プロダクティビティ（TFP）向上に寄与し得る。しかしながら、同政策に伴う人口インフローの加速は、社会保険制度におけるリスクプールのセグメンテーションとデリューションを促進し、クロスサブシディゼーション負担の非効率なリディストリビューションを拡大。これにより、アドバース・セレクションの増幅とモラルハザードのシステミックエスカレーションが観測される。
医療サービス市場においては、プライス・シグナルの失効がコモンズの悲劇（トラジディ・オブ・ザ・コモンズ）を増長し、ネガティブ・エクスターナリティとしての外部不経済が拡散。これが社会厚生のデッドウェイト・ロスの拡大を誘発し、インシュランス市場のパーフェクトコンペティションからの乖離とパレート効率性の低下を招いている。
こうした多角的課題の解決には、経験危険率（エクスペリエンス・レート）に基づくリスクベースプライシングの導入が不可欠であり、これにより保険市場の逆選択問題を軽減し、インセンティブ・アラインメントのメカニズムを最適化する必要がある。併せて、マクロファイナンス政策とのポリシーミックス調整を通じ、財政持続可能性と経済成長のトレードオフ管理を高度化することが求められる。
また、プリンシパル・エージェント問題の緩和には、ガバナンス強化と情報透明性向上を軸とした制度設計が必要であり、AIを活用したビッグデータ解析によるコンプライアンス監視と不正検知技術の導入が急務である。これにより、インフォメーションギャップの縮小と資源配分の効率化を推進し、社会的厚生の最大化を図る。
総括すれば、岩屋大臣のビザ政策緩和は短期的なマクロ経済効率性を高める一方で、社会保障システムのファイナンシャルサステナビリティに構造的リスクを導入し、そのダイナミックな最適制約下での政策的タイムインコンシステンシーが顕在化する可能性を孕む。したがって、これらの複合的トレードオフを踏まえたマルチレイヤードかつシステムインテグレイテッドなポリシーデザイン及びマネジメントが喫緊の課題となっている。
https://sanseito.jp/2020/hashira03/
参政党の経済政策、これだけはまともかと思ってたがよく分かんねぇこともけっこう書いてるな。
名目成長率4％経済を実現 ← ①インフレ目標2％ ＋ ②実質成長率2％
問題はこれらだ。
単純に意味不
デジタル編発行で国債をお金に替えるは意味が分からん。まず発行した国債を日銀が購入してる時点で国債の現金化は完了している。その国債の返済をデジタル円という政府発行通貨＝政府負債で償還出来るようにしたとして何の意味があるのか分からない。現状でも日銀当預の金なんか単位が同じ円なだけで預金通貨と現金みたいに別の通貨みたいなもんだし。
マネーの発行は日銀に任せればいいし、国債も60年償還ルールとかいう日本独自の意味不制度廃止して日銀購入分は現状の国債を無利子の永久債化するとかすればいいだけ。
通貨の概念を変え、ブロックチェーン革命で世界に先駆けてトークンエコノミーを実現し、高い生産性と利便性の高い人間本位の経済を構築。
ノリで書いたとしか思えん。ブロックチェーン使うと日本中の通貨やらの行き来を全て記録することになる羽目になるが普通に計算機資源の無駄遣いでは？
まぁ自分のプログラミング初級者時代を振り返れば複数のソースコードからなるプログラムをどうやって動かすのか？とか、ライブラリやAPIをどうやって利用したら良いんだろう？とか、返されたCSVをどうやって整形したら良いんだろう？とかそういう事に悩んだ記憶はある
プログラミングを続けていると段々と規模が大きくなってソースコード管理がしにくくなって来るけど、元増田の方法なら図になるからソースコード管理が楽になるし外部からの読み込みもフローに組み込みやすいのでプログラミング初級者には合ってると思うよ
フローさえしっかりしとけばこんな抽象的な表現でもイケるんかｗ
生成AIは最近色出来るようになってきて驚きが少なくなってきたが久々に衝撃的な内容だ
かなり書きやすいじゃん
元増田はフローチャートのステップという点に目をつけて自然言語の散文という曖昧さを許容しつつも処理の流れの固定化を実現しようとしてる
プログラミング始めたての人はアッチもコッチもと手を付けてプログラムのフローがメチャクチャになりがちだけど、元増田の方法を使うとゲームならキャラクターはキャラクターの処理をステージはステージの処理を書くことになるのでシンプルな記述になりやすい
完全に文章でAIへお願いしてコードを生成すると曖昧な部分を勝手に補完して想定通りの動作をしないってことが多々あるけど、DOT言語を使うことで記述フォーマットの統一ができて、かつ、フローの流れまで可視化できるのか
ここで言う「プログラミング初級者」とはプログラミングの記述が上から下へ向かって順番に処理されること、条件分岐やループという概念があることを理解しており、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.5Flashへ「下記のデータ記述言語のDOT言語で記述された処理フローをJavascript言語へ変換をしWebページ上へ「Hello,world」を表示したいので変換をお願いします。」と命令すると以下のコードが生成されました。
<!DOCTYPEhtml>
<html lang="ja">
<head>
<meta charset="UTF-8">
<metaname="viewport" content="width=device-width, initial-scale=1.0">
<title>Hello World Page</title>
</head>
<body>
<divid="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言語ならそこそこ普及してるしプログラミング初級者でも扱えるんじゃね？」と業務中に発想したものを書き留め公開いたしました。
何かプログラミング有識者の皆さんからより良い発想があれば参考にしたいと考えていますのでよろしくお願いいたします。以上。
Permalink |記事への反応(36) | 19:36
PS5 PSPlusのフリープレイでディアブロIV[ ベーシックセットが来た
↓
あんまり興味なかったけど知り合いがハマってるって聞いてたので話の種でDLした
↓
ゲーム開始するまで異様にめんどくさかった
↓
あれこれやってちょっとプレイしてあんまり面白くなかったのでやめた
↓
自認としては6030円払った覚えなかったんだけど
あーこれが俗にいうダークパターンか、と
確かにちょっと酒入ってたけど6030円課金します？のフロー無意識で承諾しないと思うのよね
癪だったのでPSN、ブリザード社双方のユーサポで訴えてみたんだけど、
どっちも返金には応じない、との返答
今後はフリプだからって安易に触らないようにしようという知見を得ましたー
PSPlius解約しよ
皆様もお気をつけてー
前提
自分で言った締め切りをぶっちぎる上に報連相もできない無能カスだけど、詰められるの嫌だからどうにかしたい。
長らく放置していた打ち合わせための打ち合わせをする。
やりたいこと
自分がとんでもないやつだと理解していて、それで迷惑かけていることは自覚していることを示した上で、話を先に進めたい。
（情報全部一気に詰めようとする、
自己保身のために自分がいかにカスでその自覚があるか、自分の考えにどんな問題点があるかを分かっていることを伝えようとする、
言い回しが致命的、
根回しが死ぬほどできない）
何を話すかだけじゃなくて、話を出す前にどうするかとかも教えてくれるから助かる
どんなにヤバい状況でも、どうしたらいいか聞いたら一般的なセオリーを淡々と教えてくれるのも助かる
仕事というものは、基本的に他者との意思疎通を前提として成り立っているはずだ。
しかし現実には、最も基本的な伝達すら機能しない環境が存在する。
そして不幸なことに、そうした環境の中心にはたいてい「説明しない上司」がいる。
最低限必要な要件でさえ、こちらが問いを立てなければ開示されない。
質問をすれば答えるが、逆に言えば、質問しなければ何も始まらない。
説明責任を自覚している様子はなく、「分からないなら聞けばいいじゃないか」というスタンスが徹底されている。
当然ながら、この手の人は質問に対する回答も極めて断片的だ。
前提条件の説明が抜けている、固有名詞の指す対象が不明瞭、業務フローの一部しか語られない、そのどれもが日常的に発生する。
そして、こちらが「なぜその情報が初手で出てこなかったのか」と問えば、「それは常識だと思っていた」と返ってくる。
常識の定義は個人差がある、という社会人としての最低限の認識もないらしい。
こうした対応が繰り返されるうちに、私はある仮説を立てるようになった。
この上司にはASD（自閉スペクトラム症）傾向があるのではないか、と。
ただ、対人コミュニケーションにおいて「相手の視点を想定する」という発想が極端に欠落している様子を日々目の当たりにすると、そういう可能性を視野に入れざるを得ない。
例えば、相手の理解度に応じて説明のレベルを調整することができない。
言葉の省略や抽象化が過剰で、相手が混乱していることに気づかない。
また、急な変更や例外的な対応に過敏に反応し、臨機応変な調整を極端に嫌う。
感情的に荒れることは少ないが、冷淡かつ機械的で、人間関係の機微にはまったく興味を示さない。
問題なのは、こうした人間がなぜか「ロジカルで落ち着いている」と評価されやすいことだ。
実際には、情報の交通整理ができていないだけでなく、相手に誤解させるリスクの高い話し方をしているにもかかわらず、「感情に流されず理知的に振る舞っている」と誤解されてしまう。むしろ非効率なのに。
そして、その非効率の尻拭いは部下が行う。
上司本人は、まるで自分が全体をコントロールしているかのような顔をしているが、実態は違う。
彼が話すべきだったことを、我々が代わりに補っているだけだ。
意思疎通が致命的に困難な人間に、なぜマネジメントを任せるのか。なぜ組織はそれを放置するのか。
能力のある個人が去っていき、情報を出さない人間だけが残る組織に未来はあるのだろうか。
いま私は、自分のタスクよりも「上司との会話設計」に神経を使っている。
それでも、誰も問題にしない。上司に意見すれば空気が悪くなるからだ。
まだ同じグループの他メンバーを推しているので、その人の情報はかなりしっかり入ってくる。
今思えば、昔から危うい人ではあった。
他人からの誘いを断らなさすぎることを、他のメンバーに「ちゃんと断った方がいい」と怒られていた。
ファンの1人からでも文句が出るくらいなら、全員から褒められない方がまだマシ。
「俺なんか」が口癖。
また、気がつくと他のメンバーの言った言葉を、自分の言葉のように使っていたりする。
それも、自分が他人にはみ出すのではなく、自分が他人に侵食される形でズレているのだ。
他のオタクが言っていた「鏡のような人。相手の願望を汲み取って、変幻自在に求められる姿を映す」という言葉が頭に残っている。
学歴でどうこう言うつもりはないが、それ相応だった。飛び抜けてアホでもないが、少なくとも賢くはない。
文章を読むのは好きなようだが、言葉の使い方が間違っていることもよくある。
そんな少し抜けていて、自己犠牲的で、自信のない推しが可愛かった。
そういうところを可愛いなんて言葉で消費したオタクが悪かったのかもしれない。
やけに自信を持つように変わったのは、いつからだろう。
全曜日レギュラーを制覇した時か、メンバー脱退の時か、経済番組を始めた時か、サラリーマンになった時か、出資を始めた時か。
自信を持つことは悪いことじゃない。
最初はそう思っていた。
多分、もてはやされすぎたのだ。
自信のない少しおバカな男の子が、そのまま40になって、芸能界屈指の地位と名誉、そしてお金を手に入れてしまった。
そういうことだったんだと思う。
彼の初めの出資先の一つは、かなり怪しい寄付プロジェクトだった。わりと炎上した。
これについては不快で耳に入れていなかったので詳しい部分は説明できないから、勝手に語るのはやめておく。
また、気がつくとAI開発にも手を出していた。彼のソロプロジェクトで、やけに特定の会社(しかも1ミリも聞いたことのないベンチャー企業)のサービスが使われるようになった。どうやらその会社に出資しているらしいというのが分かったのは、後からだった。
こちらも最初はそこまで違和感なかったのだが、今かなり怪しい動きをしている。
具体的に言うと、
・チケット申込サイトも独自に作成(なぜかGoogleフォーム)
・申込フォームがほぼ手入力、かつ画面側での入力値チェックがほとんどないという、ヒューマンエラーを想定していない仕様(まぁGoogleフォームだからな)
・予想通り、ヒューマンエラーによる申込失敗、確認のための問い合わせが増加
・問い合わせが増加したことに対し、「良識と節度ある問い合わせを」とか言い出す(この辺でうっすらヤバいなと思い始めた)
・購入に関しても、ヒューマンエラーによる失敗が多数発生。問い合わせが殺到したことに対し、注意喚起のような高圧的な文面で一斉メール(「ここまでご案内した対処方法を実施された多くの方が、無事に購入を完了されております。 」と、普通にやれば出来るだろアピール)
・上記の購入失敗事例を一斉メールしたことで、間違えて複数回購入してしまった人が発生し、それに対して他人後のような文面(明らかにお前の注意喚起のせいだろ。ちなみに謝罪なし)
・一連の申込フローに対するクレームが増加したことに対し、再度「マナー」という文言を件名につけて再度一斉メール(クレームが多いことへのクレームってすごい、しかも結構自業自得なのに)
前の事務所なんて、高校生の世間知らずな私が間違えて二重振込みをしてしまった時に、向こうから電話をかけてきて、親切丁寧に返金を受け取れるように説明してくれた。それを標準的にやれとは言わないが、あまりにもギャップが大きかった。
とにかく一貫して、間違う方が悪い、言う通りにすればできるだろ、という態度が滲み出ているのだ。
チケット購入までの作りがどう考えても、一般向けじゃない。不親切。
B to CのサイトをSEのデジタルリテラシー基準で考えるな。利用者は間違うものだ。
しかも推しのファンの年齢層的に、結構IT弱めの層がいることは、少しでも調査すれば想像がつく。
ていうかそもそも、ドーム公演やってるアイドルだぞ。たとえファン全員が20代だったとしても、それだけの人数がいれば、申込サイトの使い方を理解するのが下手な人なんて確実にいるだろ。
注意喚起しなければいけないほどヒューマンエラーが多発しているのであれば、それはシステムの設計が悪い。
ヒューマンエラーがごく少数なのであれば、全体への注意喚起メールなんて送らなくていい。
どちらにしても、対応が悪すぎる。
客をなんだと思っているんだ？
しかも、クレームが上がっている旨を推し本人に伝えているらしく、本人から「公演内容以外の部分は温かい目で見てほしい」というようなメッセージがあった。
いやいや、むしろ公演内容こそ実験的なものでも推しさえ出てれば温かい目で見守るけど、チケットサイトで客使ってテストすなよ。本番やぞ。
せめてまず実験するとしても、チケットの受け取り方法だけNFTを導入して、販売は通常通りぴあに委託しますとかだろ。リソースや経験がないなら段階を踏みなさい。
そのレベルのチケットサイトすら作れないなら、自前で開発しようとすんな。
とにかく、普通なら「あれ？」と違和感を感じるような会社(あるいは人？)に対し、出資するという判断をしてしまう推しの判断力のなさ。
あるいは騙されたのかもしれないが、騙されたことを見抜けない推しの愚かさ。
別に推しの判断力のなさも愚かさも今に始まった事ではないが、恐らく不相応に富や名声を持ちすぎたのだ。
出資というと聞こえはいいが、上手く騙されて乗せられて金を吸い取られてしまって、社長とかいうハリボテの立場だけを得たのではないかと思う。
そう考えると、やけに毎回出資先のオタクへの態度が高圧的なのも理解できる。きっと推しも同じように押し切られたのだろう。
まぁここまでなら、ただ単にクソみたいなチケッティングでしたという、オタクの愚痴あるあるなのだが、他にもうっすら気になっていることがある。
なんなら、こっちの方が雲行きが怪しい。
というのも、推しが最近、小麦アレルギーだと診断されたと話している。
公表していなかったところを公表したとかではない。そもそも、彼はうどんやパスタが好きで、それらを食べているシーンもたくさんあった。
そばも十割蕎麦などではなく、立ち食い屋さんで食べるような、恐らく蕎麦粉の割合が5割以下の普通の蕎麦だ。
いや、麦焼酎はギリいけて、小麦製品はダメなんですとかなら分かる。少しでも麦が入ってたら口にできませんも分かる。
どら焼きがいけて麦焼酎が無理はどう考えてもおかしいだろ。しかも40超えて急に。
しかも、話ぶり的に、検査をして初めて分かったというような感じのだ。
恐らく血液検査なのだと思うが、症状の出てないものに対してアレルギー検査をするのも、その結果だけを踏まえて対処するのも、微妙に引っかかる。
また、病院のことを「クリニック」と呼んでいて、しかも、どうにも普通の診療とは思えない生活面の細かいところまでアドバイスを受けているようなのだ。
一つ一つは取るに足りないことだが、全体的に様子がおかしい。この感じ、伝わるのだろうか？
考えすぎかもしれないが、「先生」とやらが、推しを周りから孤立させるために、アルコールや小麦製品を控えさせる方向に扇動しているのかもしれないと思っている。
特にメンバーがお酒(中でも麦焼酎)が好きなので、メンバーから距離を離す意図があったのではないか？と。
この出資とアレルギー、2つの件が繋がってるのかは分からないが、とにかく、膨大な資産と共に社会に無防備に放り出された推しが、魑魅魍魎に絡め取られようとしているような気がするのだ。
オタクは無力だ。
救う必要がないなら、それでいい。
杞憂ならそれでいいんだけど。
