リムナンテスは愉快な気分

徒然なるままに、言語、数学、音楽、プログラミング、時々人生についての記事を書きます

Rustを読むための知識

Rustの読み方

公式のThe bookを読むのが面倒臭い。 これさえ分かってれば何が書いてあるかは分かるっていうのを整理したい。 お勉強中なので、間違いあったらコメントに。

用語・概念比較

概念・単位 C/C++ Python Rust
単一ファイル ソースファイル(.c/.cpp モジュール(.py モジュール(mod/.rs
外部コード ライブラリ パッケージ クレート
パッケージマネージャー cmake pip/uv cargo
外部コードの読み込み #include <header.h> import module use crate::module;

quick start

Rustのインストール後、下記を打つ。

cargo new project
cd project
cargo run

コンパイル完了すると下記が出る。

Hello, world!

以下のエラーが出る場合がある。

error: linker `link.exe` not found
  |
  = note: program not found

note: the msvc targets depend on the msvc linker but `link.exe` was not found

note: please ensure that Visual Studio 2017 or later, or Build Tools for Visual Studio were installed with the Visual C++ option

note: VS Code is a different product, and is not sufficient

もしコンパイルエラーがでたら、Build Tools for Visual Studioを入れて「C++ によるデスクトップ開発」をインストールする。

クレート

.toml[dependencies]に記述するとダウンロードされる。 もしくはcargo addすると追加される。

変数

Rustには「所有権」なる概念があるが、要は「並列処理を安全に行う」ために存在している。 マルチスレッドでバグる原因は、データ競合(別のスレッドが同じデータを書き換えてしまう)するから。 これを防ぐためにRustでは、データが読みたいだけなら読み取り専用(&x)で参照し、データの書き換えが必要なら独占書き換え(&mut x)する、というのを明示的に指定する。

コードの書き方 正式名称 データの「権限」 使うのはどんなとき?(目的)
x 所有権(移転) 譲渡(使い捨て) ・そのデータをこの後もう使わないとき
・相手にデータを完全に引き渡すとき
&x 不変の参照 読み取り専用 ・そのデータをこの後も使うとき
・相手に中身を見るだけにさせるとき
&mut x 可変の参照 独占編集モード ・そのデータをこの後も使うとき
・相手に中身を書き換え(変更)させるとき

変数の一生

[1. 実物 (x)] ──(貸し出し)──> [2. 読み取り専用 (&x)] ※何人でもOK 
    │ 
    └───(独占貸し出し)───> [3. 独占編集モード (&mut x)] ※世界で1人だけ
  • 実物(x): データを生み出した直後の状態。
  • 読み取り専用(&x): 実物から「ちょっと見せて」と枝分かれした状態。全員が「見るだけ」なので、何人に貸し出しても絶対に安全。
  • 独占編集モード(&mut x): 実物から「ちょっと書き換えるわ」と枝分かれした状態。書き換え中に他人が見るとバグるので、必ず世界で1人だけが独占する状態になる。

判断

  • 記号なし(x) = 「あ、これでこのデータは使い捨て(引っ越し)だな」
  • & がある(&x) = 「あ、ここは安全に見るだけの処理だな」
  • &mut がある(&mut x) = 「あ、ここで中身を書き換えてるな」

エラー処理

関数の返り値はResult<()>型で返すのが定石。 末尾の ? は、「失敗ならその場で即エラーをリターンする」というショートカット記号。

LLMとエントロピー収支

※ この記事は覚書のため、今後、内容の大幅な変更が予想されます。

生命とは何か?

これはシュレディンガーの有名な著書だが、
我々自身はエントロピーを食って生きている。
情報世界に対して我々はエントロピーを下げることこそが求められているはずである
どうすればnegentropyを注入できるか

LLMが登場して、何が起こったか。

LLMを使うと、物理世界では当然エントロピーを増大させる。電気使ってGPU回しているのだから。
熱を放出しまくって信託を受けているというわけ。

一方で、情報世界ではエントロピーは減っているように見える。
データから意味を抽出しているならエントロピーは減っているし、
そもそも、出力がランダム列ではない以上、ランダム以上の秩序が含まれるはずなのである。

我々は物理的排熱と引き換えに、局所的な、情報の秩序を得ているといえる。

しかし、本当にそうだろうか。
長期的視点に立つと、情報の熱的死が起こる。
平均回帰みたいな考え方があるが、要はLLM同士が再帰すると、稀だが重要な情報が切り捨てられていく。

あるいは、そんな難しいことを考えなくても、
LLMを使ってただただ無秩序を生み出している人間もたくさんいるではないだろうか。
LLMによって却ってブルシットジョブが増えると指摘している人もいる。

果たして、「LLMによって得られるGain > LLM使用コスト」というエントロピー収支は成立させられるのだろうか。
これができないのであれば、LLMに未来は無い。

Python使ってWeb APIのリクエストヘッダでunicode文字列を送りたい

結論

strings.encode("utf-8").decode("latin-1")

※ただし受け手側がバイト列をutf-8でdecodeする仕様になっていたらの話

仕組み

この方法では、「UTF-8でエンコードされたバイト列を、無理やりLatin-1(ISO-8859-1)として解釈(デコード)する」という操作をさせている。

つまり、Unicodeを無理やり1バイト文字の羅列としてしまえば、ヘッダーにねじ込むことができるのだ。

例えば、「あ」(U+3042)という文字で考えてみよう。
これは当然latin-1には含まれない文字なので、そのままリクエストヘッダーの値に入れると処理系で弾かれるはず。

encode("utf-8")

と、いうことで、まずは「あ」をバイト列に変換する。
「あ」という文字をutf-8でバイト列に変換すると、

0xE3 0x81 0x82

decode("latin-1")

得られたバイト列を強引にlatin-1で

• 0xE3 → ã
• 0x81 → (未使用)
• 0x82 → (未使用)

と解釈すると、

ã\x81\x82

というlatin-1の文字列が得られる(latin-1では0x7F-0x9Fが使われていないので、\x81\x82のようにそのまま表示されている)。
この文字列はlatin-1なので、リクエストヘッダーに突っ込んで問題なく送ることができる。

原理

HTTP/1.1では、リクエストヘッダにasciiまたはlatin-1しか使用することができない。

そのため、一旦utf-8のバイト列に変換して、latin-1の文字列に偽装すると、データを壊さずにそのまま送ることができる。

utf-8もlatin-1もascii互換なので、(元のunicode列に混入させない限りは)復元可能。

プロンプト「以前」の思考法:LLMにおける「情報解像度」と「エントロピー」の動的制御論

序論

どいつもこいつも生成AI、LLMである。
私も例に漏れず、記事の殆どをAIに作らせるようになってしまったけれども。

みんな挙ってAIを使いこなすためのテクニックを競い合っている。「神プロンプト」とか言って(笑)。
しかし、従来のプロンプト・エンジニアリングなるものは単なる表層的介入に陥っていると言いたい。大規模言語モデル(LLM)とのインタラクションの本質は、言語的指示のパッチワークではなく、有限な計算リソース(Attention)を確率空間内のどの座標へ、いかなる密度で配分するかという「エントロピー制御」に他ならない。従って、情報理論や熱力学的視点から、LLMに対する実践的介入方法の再構築を試みるべきなのである。

この記事では、入力解像度と出力エントロピーの相関をトレードオフとして捉え、推論空間における「拡散(Exploration)」 「翻訳(Translation)」「凍結(Freezing)」の三相を動的に遷移する知能制御の能動的方法論を定性レベルで提示する。なので数理的な証明や分析は述べないし、そもそも最初から考察していない。チラシの裏のただの妄言だと思ってくれて構わない。でも、そうであったとしても依然として、我々が目指すべきは「洗練された完璧なプロンプトの作成」なんかでは決してなく、AIの推論を論理的必然性へと導く「情報制御法の獲得」である。


第1章:入力解像度と出力エントロピーの同期

この章の核心は、「高すぎる入力解像度は、未分化な対象(カオス)を扱う際に、逆にノイズを生み、AIの創造的ポテンシャルを窒息させる」という逆説の理解にある。プロンプトの精密さは固定された「能力」ではなく、出力の目的に応じて調整する「動的ズームレンズ」であり、AIの計算リソースを最適配分するための「戦略的変数」である。

1. 制御変数としての「入力解像度」:束縛条件の密度設計

プロンプトの解像度とは、単なる情報の詳細さではなく、AIの推論を特定の座標に縛り付ける「束縛条件(Constraints)の密度」である。

  • 低解像度入力 (潜在空間の開放):
    • 定義: 抽象的な問い、断片的なデータ、制約の意図的排除。
    • 効果: LLMの「潜在空間(Latent Space)」における移動距離を最大化する。具体的な制約(重力)を外すことで、AIが持つ広大な知識ネットワークを縦横無尽に走らせ、ユーザーの予期しない、エントロピーの高い(情報の新奇性が高い)接続を誘発させる。
  • 高解像度入力 (推論の物理的封鎖):
    • 定義: 厳密な定義、多層的な制約、論理構造の指定(スキーマの強制)。
    • 効果: AIの推論を特定の「解(一意の点)」に収束させる。解釈の余地を物理的に封鎖し、実務における「実装」「整合性」を担保する。

2. 同期のメカニズム:計算リソース(Attention)のゼロサム・ゲーム

LLMが一度の生成に割ける計算リソース(Attention)は有限の定数である。入力解像度と出力エントロピーが同期していない場合、内部で「リソースの奪い合い」が発生し、出力の質が著しく低下する。

フェーズ 求める出力の状態 入力解像度 実行される処理とリソース配分(戦略)
拡散 (Exploration) エントロピー(意外性、広がり) (広角) 「素材の収穫」に全振りする
制約維持コストをゼロにし、潜在空間の探索距離を最大化させる。
収束 (Refinement) エントロピー(厳密性、一貫性) (望遠) 「構造の維持」に全振りする
探索コストをゼロにし、収穫した素材を精密なテンプレートへ物理的に固定する。

3. なぜ「同期」が必要なのか:2つの致命的な機能不全

  • 過剰同期の罠(創造的窒息): 低エントロピーな出力(定型的な回答)が欲しい段階で、最初から最高解像度の設計図(厳密すぎる制約)をぶつけると、AIの計算リソースは「複雑な制約条件(構造)の維持」に食い潰される。結果、肝心の「内容の生成」に割くリソースが枯渇し、中身の薄い、一般論に終始した「型だけ立派な無味乾燥なゴミ」が生成される。
  • 不足同期の罠(実務的崩壊): 高い厳密性が求められる最終局面(実装や契約書作成)で入力解像度が低いままだと、出力に制御不能な「ゆらぎ(ノイズ)」が混入する。AIは余った計算リソースを「勝手な解釈(ハルシネーション)」に転用し、実用に耐えない致命的な欠陥を生み出す。

4. 戦略的態度:AIの「窒息」と「迷走」をナビゲートせよ

我々の役割は、単なる命令者ではなく、AIのリソース配分を司る「エネルギー・ナビゲーター」である。

  • 拡散フェーズ(探索): 「戦略的な曖昧さ」を維持せよ。AIに自由を与え、潜在空間の果てまで走らせることで、情報のポテンシャル(可能性)を最大化する。
  • 収束フェーズ(凍結): 「冷酷な独裁者」として振る舞え。解像度を極限まで引き上げ、AIの自由を奪うことで、精度の高い一撃を放たせる。

「今、自分はAIに『カオス』を求めているのか、『ロゴス』を求めているのか。この問いに答えを出すことこそが、プロンプトを書き始める前の、最も重要な知的な仕事である」


第2章:創発的要素の識別と暫定モデルの構築

本フェーズの目的は、第1章の「拡散」で得られた未分化な素材(カオス)を、自分の思考の論理体系(ロゴス)へと翻訳し、成果物の核となる「論理的リソース」を特定することにある。

1. なぜ「中間フェーズ」が必要なのか:断絶の回避

多くの指示が失敗する最大の原因は、第1章(拡散)からいきなり第3章(完成)へジャンプしようとすることにある。

  • 拡散直後の状態: 可能性の塊であるが、同時にノイズやハルシネーションを孕んだ「未分化な素材」。
  • 完成に必要な状態: 厳密な制約条件によって一意に固定された「設計図」。

この間にある「どの素材を使い、どう並べるか」という主導的な意思決定を飛ばすと、AIは重要でない枝葉に計算リソースを浪費し、精度が著しく低下する。本章はこの「ミッシングリンク」を埋めるための、人間による「編集」と「建築」のプロセスである。

2. 三つの実践的ステップ

① 蒸留とパターン認識(「砂金採り」による核の抽出)

AIの冗長な回答から、価値ある「情報の核」を特定し、背景にあるルールを読み解く。

  • セマンティック・抽出: 課題の本質を突いている「キーワード」や「概念の塊(チャンク)」を、砂金のように掬い上げる。
  • 潜在構造の検知: AIが提示したバラバラな要素の間に存在する「隠れた法則」や、AI自身も明文化していない「相関関係」を特定する。
  • バイアス判定: 回答の偏り(一般的すぎる、特定の分野に寄っている等)を客観的に評価し、次フェーズでの修正指針とする。

② スキャフォールディング(「思考の仮置き台」による骨組みの形成)

抽出した素材を、自分の既存の知見やフレームワークという「使い慣れた道具」に当てはめる。

  • 変数の仮決定: 成果物を構成する主要なパーツに「ラベル」を貼り、後続プロセスでの制御対象とする。
  • インターフェースの設計: 収集した素材を、自分の既存の論理体系の「どこに差し込むか」という接続点を設計する。
  • 解像度の段階的移行: 「曖昧なアイデア」を「定義可能な概念」へと昇華させ、第3章の「構造の凍結」に耐えうる強度を持たせる。

③ 選別と棄却の審判(「ロジックの剪定」による純度向上)

「AIが生成したから」という受動的態度を捨て、自分の論理に照らして情報を厳格に切り捨てる。

  • 採用(資産化): 自身の論理で説明可能であり、かつ目標達成に直結する要素を柱として残す。
  • 棄却(除染): もっともらしいだけの嘘(ハルシネーション)や、本質をぼやけさせる冗長な装飾表現を徹底的に排除する。

3. 本フェーズの到達点

本章を終えた時、手元には「戦略的な骨組み(スケルトン)」が残っている必要がある。人間が「編集者」あるいは「建築士」として主導権を握り、情報の優先順位を確定させることで、初めてAIは「あなたの指示で動ける」状態(第3章)へと移行可能になる。


第3章:厳密な論理制約による構造の凍結

本フェーズの目的は、暫定的なモデル(足場)を、厳密な定義と多層的な制約条件によって「一意の解」へと固定(フリーズ)し、実務や研究において「これ以外の形ではあり得ない」という論理的必然性を持った高精度な出力を強制することにある。

1. 高解像度プロンプトへのパラメータ置換:推論空間の物理的封鎖

第2章で特定した「変数」や「関係性」を、AIの自由度を極限まで奪う具体的な指示セットへと変換する。

  • スキーマの強制(型の鋳型): 「内容を要約せよ」といった抽象的な指示を排し、出力形式を「JSONスキーマ」「特定の論理フレームワーク(例:序破急、MECE)」といった「型の鋳型」へと厳密に流し込む。これにより、AIが余計な解釈に計算リソースを浪費することを防ぎ、構造を物理的に固定する。
  • 境界条件の設定(排他的封鎖): 「何をすべきか」以上に「何をすべきでないか(禁止事項)」を多層的に設定する。専門用語の使用制限、文字数制限、特定のキーワードの排除など、AIの推論が拡散(リーク)する余地を物理的に封鎖し、エントロピーを強制的にゼロへと近づける。
  • コンテキストの再注入: 低解像度フェーズではあえて伏せていた、専門性の高い高度な知識や固有のルールを、この段階で一気に結合させる。

2. 「構造の保存」と再帰的リファインメント

自身の論理体系(アーキテクチャ)と、AIの生成プロセスを完全に同期させ、出力の品質を保証する。

  • 論理的整合性の検証: 生成された各要素が、全体の設計図と矛盾なく接続されているかを、自身の知見に照らして評価する。
  • 再帰的修正(部分的凍結): 出力の一部に「ゆらぎ(曖昧さ)」や「ハルシネーション」が残る場合、その箇所のみを抽出して再度「凍結」のための追加制約をかけ、部分的な解像度を極限まで引き上げる。

3. 本フェーズにおける「凍結」の定義:偶然性から必然性へ

「凍結」とは、AIの出力から偶然性(たまたまそう答えた)が消え、指示という重力によって「この制約下では、この答え以外になり得ない」という論理적 必然性に到達した状態を指す。

  • 収束のサイン: AIの出力が、定義したテンプレートの中に過不足なく収まり、かつ実用上の「あそび(ノイズ)」が許容範囲内にまで削ぎ落とされた状態。
  • 失敗の定義: 第3章の凍結が甘い場合、第1章・第2章で得た優れた洞察も、出力の段階で「一般論に終始した、ボヤけたゴミ」へと劣化する。

「AIに自由を与えて良いのは『拡散』の時だけである。成果を求める『凍結』のフェーズでは、AIの自由を奪うことこそが、精度の高い一撃を放たせる唯一の手段となる」


第4章:動的同期プロトコル

本章の目的は、1〜3章のプロセスを単なる順次処理から、状況に応じて最適な経路を選択・循環させる「動的制御システム」へと昇華させることにある。

1. タスク診断:エントロピー位置の2軸測定

実行前に、対象タスクを「目的地の明瞭さ」と「素材の有無」の2軸で評価し、最適な実行パターンを決定する。

  • 垂直軸(目的の確定度): ゴール(型)が既知か、未知(カオス)か。
  • 水平軸(アプローチの方向): ゼロから広げる(拡散)か、既存データから導く(帰納)か。

2. 戦略的実行パターン・マトリクス

診断結果に基づき、以下の4つの基本プロトコルから選択する。

パターン名 構成パス 最適なユースケース 核心的戦略
① フル・シンクロ 1(拡) → 2 → 3 新規概念の構築、未知の課題解決 AIに「嘘(拡散)」を許し、人間が「砂金(核)」を拾う。
② 弁証法的拡張 1 → 1' → 2 既存の枠組みの打破、多角視点 意図的に「対立する前提」をぶつけ、一般論を破壊する。
③ 帰納的マッピング 素材 → 2 → 1 データの構造化、本質の逆引き 高解像度の「事実」から、低解像度の「法則」を抽出する。
④ ダイレクト・ビルド 1(収) → 3 定型業務、仕様の固まった実装 1章の拡散をスキップし、最初から「凍結」を強制する。

3. 非線形ダイナミクス:フェーズ・ループと逆行

「1→2→3」の直線的進行が行き詰まった際、意図的に解像度を上下させる機動操作を定義する。

  • 再帰的リファインメント(3 → 2 → 3): 成果物の「型」は正しいが「密度」が不足している場合。特定の変数のみを「未分化(2章)」に戻して再定義し、再度「凍結」する。
  • 破壊的リブート(3 → 1): 局所最適化(袋小路)に陥った場合。すべての制約条件を破棄し、あえて極低解像度(1章)へジャンプして、思考の蒸気(カオス)に戻す。
  • 部分的解凍(Partial Thawing): 全体構造を維持したまま、特定のモジュールだけエントロピーを上げ、AIの創造的介入を再要求する。

4. プロトコル・ヒューリスティクス(運用の黄金律)

最小の計算リソースで最大の結果を得るための、実戦的な判断基準。

  • 「2章(翻訳)」スキップの条件: 変数の抽出やラベル貼りが不要なほど、アウトプットの「型」が自明である場合(効率化)。
  • 「3章(凍結)」スキップの条件: 結論を出したことよりも、情報のポテンシャル(可能性)を維持し、自分の思考を刺激し続けたい場合(知の保留)。
  • 逆相関の法則: 「プロンプト(入力解像度)」にトークンを割くほど、「回答(出力エントロピー)」は絞り込まれ、必然性が増す。逆に、指示を短く(低解像度)するほど、AIの計算リソースは「潜在空間の探索」へ開放される。

結論:完結した「動的知能システム」

「真の知性とは、対象の混沌(カオス)と秩序(ロゴス)の度合いを見極め、それに見合った『解像度』を自在にスイッチングできる能力である」

【ストレングスファインダー】私の「エコシステム」を可視化する

ストレングスファインダー

とあるnoteの記事を見つけて、そういえばストレングスファインダーって就活のときにやったよなぁと思いだしたし、転職が頭をよぎったときも、自分の強みとは何だ?ということで振り返ってもいた。

けれども、エコシステムとして可視化まではしてこなかった。確かに、「自分の才能とはこうである」という見取り図を作ったほうが、今やってることの方向性が合ってるかどうかの検証にもなるし、無駄なことをするのを避けれられると思った。

先の記事によれば、

資質の使い方に「再現性」を持たせる必要がある

資質を普段使いできるよう再現性を出すためにも「エコシステム=自分がパフォーマンスを発揮するための資質同士のつながり」を言語化すべき

ということらしい。汝自身を知れ。


ストレングスファインダーの自己解析

私のTOP5の資質はこちら。

  1. 内省:戦略的思考力
  2. 学習欲:戦略的思考力
  3. 収集心:戦略的思考力
  4. 運命思考:人間関係構築力
  5. 個別化:人間関係構築力

私のエコシステム図

というわけでGeminiに手伝ってもらいながら、エコシステムの図を描いてみた。

上位4資質(内省 × 学習欲 × 収集心 × 運命思考)が互いに参照・補完・相互作用しながら「自分の中だけで完結する巨大な宇宙」を形成するらしい。かろうじて「個別化」が存在するので、これが唯一の「外界とのインターフェース」として機能して、他の資質が作り上げた世界を翻訳して出力することができる。個別化の負荷高すぎ。


テキスト解説

上のエコシステムは、私の資質のテキスト解説をもとに図解したもので、
これもGeminiに言語化してもらってます。

① インプット:広域変数の摂取(収集心 × 学習欲)

「役に立つか」という世俗的な基準ではなく、「まだ誰も踏み込んでいない」「世界の理(ことわり)に触れられそう」という直感で、網羅的に摂取します。これは単なる物知りではなく、後述する「演算」のための広大な変数を集める作業です。

実利や既知の境界に縛られず、系(システム)の外部にある情報を網羅的に摂取します。これは単なる蓄積ではなく、後述する抽象化演算において、より広範な「写像」を可能にするための多様な変数を確保するプロセスです。

② プロセス:構造の抽出と並行移動(内省 × 運命思考)

集めたバラバラの知識を、頭の中で抽象的な構造へと昇華させます。数学と言語を同一視するように、異なる分野を「構造の並行移動」でつなぎ合わせ、自分だけの巨大な真理のマップを構築します。

摂取した個別の事象から具体的な文脈を剥ぎ取り、純粋な「構造(パタン)」へと昇華させます。異なる領域に存在する同型の構造を見出し、それらを結合・統合(アウフヘーベン)することで、世界を記述する独自のメタ・マップを構築します。

③ アウトプット:認知プロファイリングと翻訳(個別化)

構築された巨大なマップは、そのままでは他人には理解されません。そこで「個別化」が、相手の知能レベルや背景をプロファイリングし、「相手が受信可能な周波数」に情報をダウンサイジングして翻訳します。

構築した巨大なメタ・マップを、そのままの解像度で出力するのではなく、対象(人・問題)の認知特性に合わせて再構成します。相手の前提条件や推論プロセスを逆算し、「その認知フレームにおいて最も機能する形」へと情報をダウンサイジングして提供します。

難解な概念を、特定の誰かが理解できる形に再構築して提供する「ブリッジング」において、比類なき価値を発揮します。


資質間の相互関係

1. インテーク(収集心 ⇄ 学習欲)

  • 相互作用: 「③収集心」が未知の対象(モノ・情報)を広くピックアップし、「②学習欲」がその習得プロセス(コト)を完遂させるための粘り強さを提供します。
  • 関係性: 収集心が「何を(What)」、学習欲が「どのように(How)」を担当する、インプットの双輪です。

2. 構造化(内省 ⇄ 運命思考)

  • 相互作用: 「①内省」が孤独な思考の中で知識を極限まで抽象化し、「④運命思考」がその抽象化された点と点を結びつけ、一つの巨大な「理(システム)」として統合します。
  • 関係性: 内省が「垂直的な深掘り」、運命思考が「水平的な接続」を担当し、多次元的なマップを編み上げます。

3. ブリッジ(個別化 ⇄ 他の4つの資質)

  • 相互作用: 上位4つ(内省・学習欲・収集心・運命思考)が「自分の中だけで完結する巨大な宇宙」を形成するのに対し、「⑤個別化」だけが唯一の「外界とのインターフェース」として機能します。
  • 関係性: 個別化が相手のプロファイルを読み取ることで、他の4つが作り上げた「深すぎて伝わらない真理」を、相手が理解できる形に翻訳・変換(ダウンサイジング)します。

資質同士の影響

組み合わせ 起こる現象
内省 × 収集心 闇雲に集めるのではなく、「自分の哲学の構築に必要か」という内的基準で情報の取捨選択を行う。
運命思考 × 学習欲 「この分野を学べば、あのアレと繋がるはずだ」という予感に基づき、一見無関係な分野への学習を正当化する。
個別化 × 内省 相手の思考のズレや前提の欠如を、自分の内的な抽象モデルに照らし合わせて瞬時に特定する。

資質間の抑制関係

面白いのは、「⑤個別化」が「④運命思考」を具体化させている点です。

  • 運命思考は「世界は一つに繋がっている」という全体論的な視点ですが、
  • 個別化は「一人ひとりはユニークで、他とは違う」という各論的な視点です。

この相反する視点が共存することで、「全体の構造(真理)を理解しながらも、それを個別の事象(目の前の人)に当てはめる際に、決して雑な一般化をしない」という、極めて精密な知性が生まれています。


まとめ

自分の強みとは何か、そして強み同士がどのように機能しているか、ようやく理解ができた。

生成AI以前の環境では、自分のような内省駆動の人間は考えすぎてアウトプットがおろそかになりがちだったのだと思う。ところが生成AIがやってきてくれたおかげで半ば強制的に、とりあえず見せられるだけの成果物を作ることができるようになったので、ボトルネックが解消された気分になってます。

みんな、自己を認識しよう。

C#(WPF)アプリ多言語対応の落とし穴と解決法

C#WPFアプリで多言語対応するためにリソースファイルを使おうと思ったのですが、いろんなところで躓いたので、解決策のメモです。
Visual Studio 2022です。

その1 リソースファイル/「Properties」フォルダ/「Resource」フォルダがない

プロジェクト作成直後のデフォルトの状態では、ソリューションエクスプローラーを見てもリソースファイル(.resx)や「Properties」フォルダ、「Resource」フォルダなどが見当たらないと思います。

プロジェクトを作成してデフォルトの状態ではリソースファイルが存在しません。そのため、プロジェクトのプロパティを開いてリソースファイルを作成します。
プロパティは、メニューバーの「プロジェクト」>「WpfApp1 のプロパティ」(例えば。WpfApp1のところは作成したプロジェクト名が入ります)で開きます。

「リソース」>「全般」の「アセンブリ リソースを作成する/開く」をクリックすることで、「Properties」フォルダと「Resources.resx」が作成され、ソリューションエクスプローラーに表示されます。

新しい言語のリソースファイルを追加する場合は、「Properties」フォルダを右クリック>「追加」>「新しい項目」でリソースファイルを追加できます。

その2 リソースの参照の仕方がわからない

XAML

その1のように、「Properties」フォルダにリソースファイル(.resx)が配置されているというディレクトリ構成であれば、Windowブロックにxmlns:properties="clr-namespace:WpfApp1.Properties"を挿入したうえで、

<Window x:Class="WpfApp1.MainWindow"
        xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation"
        xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"
        xmlns:d="http://schemas.microsoft.com/expression/blend/2008"
        xmlns:mc="http://schemas.openxmlformats.org/markup-compatibility/2006"
        xmlns:properties="clr-namespace:WpfApp1.Properties"
        Title="MainWindow"
        Width="300"
        Height="100"
        mc:Ignorable="d">

多言語対応したい文字列のところを{x:Static properties:Resources.String1}に置き換えて書きます。この場合、UI上の表示は、該当言語のリソースファイルの「String1」に対応する値を参照して表示します。

例えばTextBlockのTextを置き換えるのであれば、

<TextBlock FontSize="20"
           Text="{x:Static properties:Resources.String1}" />
C#

String1の値を参照する場合は、Properties.Resources.String1のように書きます。
例えば、下記のようにするとメッセージボックスの文字列に使えます。

namespace MultiLangApp
{
    /// <summary>
    /// Interaction logic for MainWindow.xaml
    /// </summary>
    public partial class MainWindow : Window
    {
        public MainWindow()
        {
            InitializeComponent();
        }

        private void ButtonText_Click(object sender, RoutedEventArgs e)
        {
            MessageBox.Show(Properties.Resources.String1);
        }
    }
}

その3 .xamlのプレビューが表示されない

一旦ビルドしましょう。ビルドに成功すれば表示されるようになります。

その4 ビルドするとエラーがでて成功しない

リソースファイルのアクセス修飾子を「Public」に変更しましょう。

リソースファイル(.rsax)を開きまして、上の方に「アクセス修飾子」があります。
デフォルトでは「Internal」になっているっぽいので、これを「Public」に変更すればビルドが通る。

楔形文字で学ばないアッカド語文法(15)G語幹I-ʾ型弱動詞

この記事は

  • G語幹I-ʾ型弱動詞
  • 不規則活用動詞 alākum「行く」

についての記事です。

弱動詞解説回ショートカット

1. G語幹I-ʾ型弱動詞の概論

第15回では語根の第一子音が ʾ の時の活用を学びます(ʾ, h, ḥ, ʿ, ġ, y、つまりʾ1-5, ʾ7、w=ʾ6は語頭で脱落しないので、別枠で第18回で紹介します)。

I-ʾ型弱動詞は、amārum や abātum など a から始まる I-a 型、epēšum や ezēbum など e から始まる I-e 型の大きく2つに分けられます。この違いはセム祖語の時から脱落した第一子音が何かによって生まれます(下の表を参照)。歴史的に、第一子音が ʾ, h (I-ʾ1-2)の語は I-a に、ḥ, ʿ (I-ʾ3-4)の語は(不定形の場合)隣接する母音が a > e に変化することで I-e になりました。また、第一子音が y (I-y; I-ʾ7)の語は I-e に合流、ġ (I-ʾ5)の語は第一子音が ḫ に変化したり、I-a になったり、稀に I-e になったり、ということで、結局は I-a か I-e のどちらかになったので、この2つを考えれば十分です。

活用の仕方は基本的にはどちらも同じで、不定形(parāsum型)、動形容詞(parsum型)では語頭に第一子音が来ますが、このときは単純に子音が無いものとみなします。過去形(iprus型)では第一子音の前の母音が長母音化します。

第一子音 分類
ʾ=ʾ1 amārum < *ʾamārum I-a
h=ʾ2 abātum < *habātum I-a
ḥ=ʾ3 epēšum < *ḥapāšum I-e
ʿ=ʾ4 ezēbum < *ʿazābum I-e
ġ=ʾ5 - *1 第一子音がḫに変化、またはI-a、稀にI-e
y=ʾ7 ešerum < *yašārum I-e に合流

G過去形の活用表

接頭辞の母音と語幹頭の母音が連続するため、I-a 型では ia > ī, aa > ā のように接頭辞の母音が伸びるように変化します。I-e 型では語幹頭の e の影響で ie > ī, ae > のように変化します。

1a2ā3um
(一般形)
> a2ā3um / e2ē3um
(I-a / I-e)
I-a (I-ʾ1-2) I-e (I-ʾ3-4, I-y)
amārum (I-ʾ1)
(見る)
abātum (I-ʾ2)
(滅ぼす)
epēšum (I-ʾ3)
(する)
ezēbum (I-ʾ4)
(捨てる)
単数 3cs i12V3 > ī2V3 īmur ībut īpuš īzib
2ms ta12V3 > [tā/tē]2V3 tāmur tābut tēpuš tēzib
2fs ta12V3ī > [tā/tē]2V3ī tāmurī tābutī tēpušī tēzibī
1cs a12V3 > [ā/ē]2V3 āmur ābut ēpuš ēzib
複数 3mp i12V3ū > ī2V3ū īmurū ībutū īpušū īzibū
3fp i12V3ā > ī2V3ā īmurā ībutā īpušā īzibā
2cp ta12V3ā > [tā/tē]2V3ā tāmurā tābutā tēpušā tēzib
1cp ni12V3 > nī2V3 nīmur nībut nīpuš nīzib

G動形容詞の活用表

通常の動詞と同様に、女性単数形で母音が出現します。

1a2V3-
(一般形)
I-a (I-ʾ1-2) I-e (I-ʾ3-4, I-y)
amir- (I-ʾ1)
(見る)
abit- (I-ʾ2)*2
(滅ぼす)
epiš- (I-ʾ3)
(する)
ezib- (I-ʾ4)
(捨てる)
男性 女性 男性 女性 男性 女性 男性 女性 男性 女性
単数 主格 1a23um 1a2V3tum amrum amirtum abtum abittum epšum epištum ezbum ezibtum
属格 1a23im 1a2V3tim amrim amirtim abtim abittim epšim epištim ezbim ezibtim
対格 1a23am 1a2V3tam amram amirtam abtam abittam epšam epištam ezbam ezibtam
複数 主格 1a23ūtum 1a23ātum amrūtum amrātum abtūtum abtātum epsūtum epsātum ezbūtum ezbātum
斜格 1a23ūtim 1a23ātim amrūtim amrātim abtūtim abtātim epsūtim epsātim ezbūtim ezbātim
なお ešērum の動形容詞は例外的に išar- という語幹を使います。

2. alākum「行く」の活用

alākum「行く」(< *halākum)はG過去形で不規則活用します。語形はI-ʾ型ですが、I-n型のように第2子音 l を重ねて作ります。幹母音は i。

1a2ā3um > na2ā3um
(一般形 > 1=n)
alākum
(行く)
単数 3cs i12V3 > i22V3 illik
2ms ta12V3 > ta22V3 tallik
2fs ta12V3ī > ta22V3ī tallikī
1cs a12V3 > a22V3 allik
複数 3mp i12V3ū > i22V3ū illikū
3fp i12V3ā > i22V3ā illikā
2cp ta12V3ā > ta22V3ā tallikā
1cp ni12V3 > ni22V3 nillik

3. まとめ

  • I-ʾ 型弱動詞では第一子音を無音として動詞を活用する。G過去形では母音変化を生じる。
  • alākum「行く」は I-ʾ 型だが、例外的に I-n 型の活用をする。

←前:楔形文字で学ばないアッカド語文法(14)同格・接続詞省略
→次:(16)?

参考文献
  • J. Huehnergard, A Grammar of Akkadian (3rd ed. 2011), Harvard Semitic Museum Studies 45, ISBN 978-1-57506-922-7.
  • D. Snell, Enkonduko en la Akadan (Tria, reviziita eldono), esperantigita de Michael Wolf, Biblical Institute Press, Rome, 1988, ISBN: 88-7653-566-7.

*1:例が見当たらなかった。

*2:資料が少ないため推測。自信ない。