  |
はてなキーワード:Testとは
日本人の平均IQは、おおよそ105〜106程度とされることが最も一般的です。多くの国際比較データや最近のまとめ（2025〜2026年時点）では、以下のような数値がよく引用されています：106.48（World PopulationReview、DataPandas、CEOWORLDmagazineなどの2025年データ）
106.3（InternationalIQTest 2025〜2026集計）
IQの「国別平均」にはいくつかの種類があり、数字がバラつく理由があります。本格的な標準化知能検査（WAISなど）の場合
日本国内で標準化されたテストでは、平均がちょうど100になるように調整されています。つまり「日本人の平均IQは100」というのが厳密な意味での正しい答えです。
世界共通の基準で比較すると、日本人は100より高い（105〜107程度）という結果が繰り返し出ています。
一部で110以上（例：112前後）と出るものもありますが、これは受験する層が偏っている（知的好奇心が高い人、英語ができる人などが多く参加）ため、過大評価されやすいです。
ストリート・エピステモロジー（SE）は、相手の信念の「内容（What）」ではなく、その信念に至った「プロセス（How）」を問うソクラテス式問答法である。陰謀論や根拠のない政治的確信に対して、直接「それは嘘だ」と指摘するのではなく、「どうすればそれが真実だと知ることができるか」を共同で探求するスタンスを取る。
オンライン上のトローリングや攻撃的なコメントに対しては、マーシャル・ローゼンバーグのNVCを応用した「脱エスカレーション・ループ」が有効である。
このプロセスは、相手の「攻撃」を「満たされていないニーズの悲劇的な表現」として再定義し、敵対関係を協力関係へとシフトさせる構造を持つ。
個人の対話スキルを向上させるだけでは、社会全体の分断は解消されない。SNSのアルゴリズムが増幅する情動的二極化に対抗するためには、デジタル空間の特性（アフォーダンス）を理解し、ネットワークレベルでの介入を行う必要がある。
政治的コミュニケーションにおいて、左派と右派には「美的非対称性（Aesthetic Asymmetry）」が存在する。歴史的に、左派は壁画やプロテストソングのような「参加型」で「構成的（Constitutive）」な芸術――コミュニティの結束を高め、希望を共有するための表現――を好んできた。一方、現代の右派（特にオルタナ右翼）は、ミームやシットポスティング（Shitposting）のような「道具的（Instrumental）」で「武器化されたユーモア」――相手を嘲笑し、混乱させ、分断を煽るための表現――に長けている。
この非対称性が意味するのは、左派的な「真面目で、説明的で、道徳的に正しい」コンテンツは、ミーム戦争においては圧倒的に不利であるということだ。ミームは文脈を剥ぎ取り、瞬時に情動（特に嘲笑や優越感）を喚起することで拡散する。
対抗戦略：脱分断ミーム（Depolarizing Memetics）
反発を招かないデジタル拡散のためには、以下の原則に基づいた新しいミーム戦略が必要である。
ネットワーク分析の研究は、SNS上の世論形成において、著名な「インフルエンサー（発信者）」以上に、「マルチプライヤー（拡散者）」と呼ばれる層が決定的な役割を果たしていることを示している。マルチプライヤーは、特定のイデオロギー・クラスター内で情報をキュレーションし、リツイートによって可視性をブーストする「ゲートキーパー」である。彼らは高い「整列スコア（AlignmentScore）」を持ち、陣営をまたぐことは稀である。
批判的メッセージを拡散させるためには、インフルエンサーを説得するのではなく、このマルチプライヤー層が「リツイートしたくなる」コンテンツを設計する必要がある。そのためには、前述の「道徳的翻訳」が不可欠である。保守系マルチプライヤーは、リベラルな正論は無視するが、「言論の自由」や「エリートへの懐疑」というフレームで語られた批判（例：「真の愛国者は、大統領であっても盲信しない」）には反応する可能性がある。クラスターの境界を浸透できるのは、そのクラスターの言語で語られたメッセージのみである。
X（旧Twitter）等のアルゴリズムは、「怒り」や「恐怖」といった高覚醒の情動を引き起こす投稿を優遇する傾向がある。冷静な対話は「退屈」とみなされ、表示順位が下がる。この構造的ハンディキャップを克服するためには、「怒り」以外の高覚醒情動、すなわち「驚き（Awe）」「好奇心（Curiosity）」「感動（Kama Muta）」を利用する必要がある。
以上の理論と技法を、一般市民や草の根活動家が実践可能な形に落とし込むためのマニュアル（ハンドブック）の設計図を以下に提示する。この構成は、米国の草の根運動ガイド『Indivisible Guide』の成功モデル（段階的習得、具体的アクション、テンプレート化）を参照している。
目的:実践者のマインドセットを「論破」から「影響」へとシフトさせる。
本報告書で提示した戦略は、短期的な選挙勝利のための戦術ではない。サイモン・シネックが言う「無限のゲーム」――すなわち、対話が継続可能であり、社会システムが崩壊しない状態を維持すること――を目的としている。
情動的二極化という「内戦」状態において、最大の勝利は敵を倒すことではなく、敵を「対話可能な競争相手」へと戻すことである。そのためには、批判者自身がまず武装（道徳的優越感）を解除し、相手の認知フレームの中に降りていく勇気を持たなければならない。この「戦略的共感」こそが、分断された世界をつなぎ直す唯一の現実的なエンジニアリングである。
戦略的共感と認知的安全保障：反発を招かない政治的批判のための包括的枠組み
現代の政治空間は、政策の不一致（イデオロギー的二極化）以上に、対立グループに対する嫌悪や恐怖といった感情的拒絶反応（情動的二極化）によって支配されている。この環境下において、伝統的な「批判」の手法――事実の提示、道徳的糾弾、論理的論破――は、その機能不全を露呈しているだけでなく、逆効果をもたらしていることが多くの実証研究によって明らかになっている。批判対象者の信念を強化してしまう「バックファイア効果（Backfire Effect）」や、批判者を存立危機的脅威とみなす「アイデンティティ防衛機制」が作動するためである。
本報告書は、心理学、認知科学、政治社会学の最新知見に基づき、政治的対立者に対して反発（バックラッシュ）を招かずに影響力を行使するための戦略的枠組みを提示するものである。ここで目指すのは、単なる「中道的な妥協」や「礼儀正しさ」の推奨ではない。人間の認知アーキテクチャの脆弱性と特性をハッキングし、相手の道徳的・感情的防御壁を迂回してメッセージを届けるための、エンジニアリングされたコミュニケーションプロトコルである。
報告書は大きく三つのフェーズで構成される。第一に、なぜ従来の批判が失敗するのかを脳科学的・心理学的メカニズムから解明する理論編。第二に、その防御壁を突破するための具体的な対話技法（ディープ・キャンバス、ストリート・エピステモロジー、NVC）を体系化した実践編。そして第三に、これらの技法を個人のスキルから社会運動へとスケールさせるための組織論と普及戦略である。
効果的な批判戦略を設計するためには、まず人間の心がどのように政治的情報を処理し、拒絶するかというメカニズムを理解しなければならない。政治的信念は単なる情報の集合体ではなく、個人のアイデンティティや所属集団への忠誠心と融合した「拡張された自己」の一部として機能している。
近年の政治心理学における最も重要な発見の一つは、情動的二極化（Affective Polarization）の実態解明である。これは、対立する政治グループのメンバーに対して「好きか嫌いか」という感情的温度差が極端に開く現象を指す。研究によれば、情動的二極化は対人関係の悪化だけでなく、個人の心理的幸福感（ウェルビーイング）の低下、社会的支援の減少、ストレスの増大といった「個人内損害（Intrapersonal Harm）」をも引き起こすことが示唆されている。特に、リベラル層において高い情動的二極化とストレス、健康悪化の相関が見られることは、政治的怒りが批判者自身をも蝕むことを示している。
この情動的二極化は、脳内で一種の「信頼のファイアウォール」として機能する。アウトグループ（外集団）から発信された情報は、その内容の真偽にかかわらず、自動的に「悪意ある攻撃」としてタグ付けされる。扁桃体が脅威を検知し、前頭前野が論理的推論ではなく「反論の生成」のために動員される「動機づけられた推論（Motivated Reasoning）」が作動するためである。この状態にある対象者に正論をぶつけることは、火に油を注ぐ行為に等しい。
バックファイア効果とは、誤った信念を訂正しようとする試みが、かえってその信念を強固にしてしまう現象である。このメカニズムには、自己肯定感の維持と集団への所属欲求が深く関わっている。批判を受け入れることは、過去の自分を否定すること（自己の一貫性の喪失）や、仲間を裏切ること（社会的死）を意味するため、脳は全力でそれを回避しようとする。
さらに、批判のフレーミング（枠組み）が、受け手のイデオロギーとミスマッチを起こしている場合、説得効果は皆無となるばかりか、抵抗を強める結果となる。例えば、新型コロナウイルス感染症（COVID-19）対策におけるメッセージングの研究では、リベラル層が「利得フレーム（マスクをすれば命が助かる）」と「損失フレーム（マスクをしないと命が失われる）」の双方に敏感に反応し、コンプライアンスを高めたのに対し、保守層はこれらのフレーミング効果に対して強い抵抗を示したことが明らかになっている。これは、問題が高度に政治化された文脈においては、一般的な行動経済学的介入（ナッジ）さえも、イデオロギーのフィルターによって無効化されることを示唆している。
批判が受容されるための極めて重要な、しかし見過ごされがちな因子として「知的謙虚さ（Intellectual Humility:IH）」がある。IHとは、「自分の知識や信念が間違っている可能性を認識する能力」と定義される。最新の研究は、対話において自身の知的限界を認める態度が、相手の情動的二極化を低減させる強力な緩衝材となることを示している。
特筆すべきは、IHが「相手からの好意（Target Liking）」を媒介して、対話への「接近行動（Approach）」を促進するというプロセスである。批判者が「私は絶対に正しい、お前は間違っている」という道徳的マウンティング（Moral Grandstanding）の態度を取ると、相手は「回避行動」をとる。逆に、批判者が「私も確信はないのだが」「複雑な問題で迷っているが」という不確実性を提示することで、相手の警戒心が解け、対話の土俵に乗る可能性が高まる。知的謙虚さは、相手の武装解除を促すための「白旗」ではなく、心理的防衛壁を通過するための「通行手形」として機能する戦略的資質である。
政治的対立の根源には、事実認識の相違以上に、道徳的直感の相違がある。リベラルと保守は、異なる「道徳の言語」を話しているにもかかわらず、自身の言語で相手を説得しようとするため、コミュニケーション不全に陥る。本セクションでは、道徳基盤理論（Moral FoundationsTheory: MFT）を応用し、批判を相手の価値観に翻訳して届ける「道徳的リフレーミング」の技術を詳述する。
ジョナサン・ハイトらが提唱した道徳基盤理論は、人類の道徳的判断が以下の5つ（または6つ）の生得的な基盤の上に構築されているとする。
実証研究が一貫して示すのは、リベラル層が主に「ケア」と「公正」の2基盤に強く依存するのに対し、保守層は5つの基盤すべて（特に忠誠、権威、神聖）を重視するという非対称性である。
多くの政治的批判が失敗するのは、リベラルが保守に対して「それは弱者を傷つける（ケア）」「不平等だ（公正）」というリベラル特有の語彙で攻撃するためである。保守層にとって、これらの価値は「忠誠」や「権威」よりも優先順位が低いため、批判は響かない。逆に、保守がリベラルに対して「伝統を破壊する（権威）」と批判しても、リベラルはそれを抑圧としか捉えない。
反発を招かない批判のためには、自身の主張を相手の道徳基盤の語彙を用いて再構成（リフレーミング）する必要がある。これを「道徳的合気道」と呼ぶ。相手の道徳的エネルギー（価値観）を利用して、相手の姿勢を崩す技法である。
以下の表は、主要な政治的争点において、従来のリベラル的批判（バックラッシュのリスク大）を、保守的道徳基盤に翻訳した戦略的フレーム（受容可能性大）に変換したものである。
| 争点 | 従来のリベラル的批判（高リスク） | 戦略的リフレーミング（低リスク） | ターゲットとする道徳基盤 |
|---|---|---|---|
| 環境保護 | 「地球温暖化は弱者や未来の子供を苦しめる。」（ケア） | 「我々の国土と美しい自然は神からの授かりものであり、汚染から守り抜く義務がある。」 | 神聖／堕落、忠誠／背信 |
| 同性婚 | 「誰を愛するかは個人の権利であり、平等であるべきだ。」（公正） | 「結婚は社会を安定させる伝統的な制度であり、同性カップルもその責任ある関係に組み込むべきだ。」 | 権威／転覆（社会秩序）、忠誠 |
| 軍事費 | 「軍事費を削って福祉や教育に回すべきだ。」（ケア／公正） | 「無駄な軍事支出は国家の財政を弱体化させ、真の国防力を損なう背信行為だ。」 | 忠誠／背信、権威 |
| 政治腐敗 | 「富裕層ばかり優遇するのは不公正だ。」（公正） | 「私利私欲のために公職を利用することは、国家への裏切りであり、高潔な職務を汚す行為だ。」 | 忠誠／背信、神聖／堕落 |
| 移民問題 | 「難民を助けるのは人道的な義務だ。」（ケア） | 「秩序ある移民受け入れは、国家の活力を維持し、アメリカンドリームという伝統を守るために必要だ。」 | 忠誠、権威（秩序） |
研究によれば、保守層に対して環境保護を「神聖さ」や「愛国心」の文脈で語った場合、リベラルな文脈で語った場合よりも支持率が有意に上昇することが確認されている。重要なのは、主張の内容（環境を守る）を変えるのではなく、その理由付け（なぜ守るか）を相手の言語に翻訳することである。
批判は通常、「現状のままでは悪いことが起きる」という損失フレーム（Loss Frame）で行われることが多い。しかし、損失フレームは恐怖や不安を喚起し、防衛的な反応を引き起こしやすい。これに対し、「ゲイン・フレーム（Gain Frame）」を用いた批判は、望ましい未来像を提示し、その実現を阻害する要因として現在の問題を指摘する手法である。
例えば、政治家のスキャンダルを追及する場合、「彼は嘘つきだ（損失フレーム：信頼の喪失）」と攻撃するのではなく、「我々は正直で高潔なリーダーを持つに値する国家だ（ゲイン・フレーム：尊厳の回復）」と主張する。このアプローチは、批判の対象を「個人」から「規範の維持」へとずらし、相手の「権威への尊重」という道徳基盤を刺激しつつ、攻撃性を緩和する効果がある。研究は、特にリスク回避傾向の強い層に対しては損失フレームが有効な場合もあるが、イデオロギー的に対立する層に対しては、ゲイン・フレームや道徳的適合性の方が「聞く耳」を持たせる効果が高いことを示唆している。
理論を実践に移すためには、具体的な対話スクリプトと手順が必要である。ここでは、異なる文脈（対面、オンライン、深い対話）において効果が実証されている3つの主要なプロトコルを詳述する。
ディープ・キャンバスは、戸別訪問（キャンバス）において10〜20分の深い対話を行うことで、トランスジェンダーの権利や移民問題などの二極化した争点に関する態度を変容させる手法である。従来の「事実の弾丸」を撃ち込む方法とは異なり、「脆弱性の交換」を通じて相手の情動的反応を書き換える。
研究によれば、ディープ・キャンバスは従来の説得手法の約102倍の効果を持ち、その効果は数ヶ月持続することが確認されている。
ストリート・エピステモロジー（SE）は、相手の信念の「内容（What）」ではなく、その信念に至った「プロセス（How）」を問うソクラテス式問答法である。Permalink |記事への反応(1) | 11:19
生成AIが直接機械語やバイナリを出力するようになるのではないか、という問いは本質的に間違っている。
自分は、まだ素朴なニューラルネットワークで光学文字認識(OCR)の精度を出していた頃から似たようなことを考えていたので、少し他人よりも蓄積がある。
これは、Large LanguageModel(LLM)を開発する企業が資金を集めるために多少誇張した未来を語るという文脈では大目に見た方が良いが、正確性に欠ける。
本質的な問いは、なぜ我々は、ノイマン型コンピュータを用いて、主記憶に置かれたプログラムをCPUを用いて実行する形式をとるのか、というものである。
まず、筋の悪い反論から説明し、妥当な反論にも触れたうえで、本質的に問うべき課題を説明する。
これは明確に、いいえ、と答えることが出来る。
最初こそ人間による補助は必要だが、LLMを含むAIは明確な目標があれば人間のデータなしでも十分に学習することが出来る。
これは身近なところでは将棋、有名なものだと囲碁で実証された研究が存在する。
そのため、単純に「機械語は人間による学習データが少ないので扱いが難しいだろう」という反論は成立しない。
そういったものはLLMではないだろうという指摘は可能だが、LLMでそういったAIを出力することは限定的とはいえ現在でもできる。将来できないと言うだけの論拠にはならない。
英語に限った話ではなく、人間が意思疎通に用いる言語である自然言語(natural language)は、曖昧さやばらつきがある。
これを形式言語(formal language)という、曖昧さを無くして語彙や文法を限定した言語に記述しなおすことで、厳密にする手法がある。
この形式言語での表現が、アルゴリズムやデータ構造になり、現代のノイマン型コンピュータにおけるプログラムそのものと言うことが出来る。
なぜ限定的かと言えば、形式言語の一種であるプログラミング言語には曖昧さが許容されているからである。
ほとんどのプログラミング言語では、同じ目的を達成する為に複数の記述が許容されている。
主に、人間が書きやすいから、とか、複数の人間で書きやすいように、といった理由で、曖昧さが許容されている。
そのため、機械へ命令するためには厳密さが必要だからプログラミング言語が必要だ、と言う反論は妥当ではあるが、弱い。
なぜ大統一プログラミング言語のように、自然言語の意図を機械に伝えるための形式言語が一種類になっていないかと言えば、人間の認知能力には限界があるからだ。
そのため、簡易で曖昧さを含むために最適化はできないが十分な性能を持つプログラミング言語や、非常に複雑で記述量も多くなるが大人数で作業するには最適なプログラミング言語などが複数存在する。
これらはいずれも、人間が楽に記述できる形式言語であったり、人間同士が齟齬なくコミュニケーションを取るために必要な形式言語である。
ありていに言って、人間や人間たちが理解可能な形式言語でないと機械にその意図を伝えることが出来ないから、と言える。
ただし、コンパイラから出力されたニーモニックやLLVM-IRを監査できる人間は現代では非常に少なく、現状ほぼ監査なく受け入れていると言って良い。
何故非常に少なくなったかと言えば、機械に伝える意図が大規模になり、単純にマンパワーが足りなくなったので監査しきれなくなっただけに過ぎない。
（もちろん、途方もない努力の末に最適化が進み、ほぼどの様な書き方をしても最適な機械語が出力されるようになったから、とも言える）
同様の理屈で、単純に大規模になり監査が間に合わなくなったので、受け入れるようになる未来が来ないとは言い切れない。
本質的な問いは、なぜ我々はノイマン型コンピュータを用いて機械に意図を伝えるのか、である。
ASIC(Application Specific Integrated Circuit)と呼ばれる、特定の用途向けの集積回路がある。
蟹チップとして、Realtek社のNIC(NetworkInterface Card)をご存じの方も多いと思う。
必要十分な処理があらかじめ定まっているのであれば集積回路を組んだ方が高効率省電力にできる。
暗号化や復号もASICで行われることが多く、ブロック暗号はその性質上集積回路での実装が容易であり、それに向けた研究も行われている。
一般的にも、ハードウェアエンコーダーなどでお世話になっている人も多いと思う。
ではなぜ、我々は身近な全てをASICにしないのか。
それは、書き換えできず、単純な処理しかできず、大量生産しないとコストに見合わないからである。
FPGAのように、ハードウェア記述言語を用いて集積回路を書き換えるものも、ほぼ同様の理由で研究開発用途や産業用途に留まっている。
（一部のPLD (ProgrammableLogic Device)は根強く産業利用されているし、大規模に展開され高効率を要求されかつ書き換えを求められるネットワーク機器では一部採用が進んでいる）
汎用的で書き換えが可能、伝える意図を変更できる様々な処理が可能な機械に価値があるから、である。
ここ半年から1年で急激にLLMの性能が上がったと感じている人と、コーディングツールとしてLLMの利用が洗練されたと感じている人の間には溝がある。
自分は、LLM自体は順調に進歩し続けているが、それほど劇的な変化はない、という立場をとっている。
これはモデルそのものが質的に大きく変化したと感じないから、である。
しかし、プログラミングの世界に限って観ると、コーディングエージェントや実利用では大きな変化があったと思う。
この、"コーディングを取り巻く環境としてのLLM利用"という文脈は、"LLMの進化"という文脈とは異なる、という点は頭の隅にでも覚えて帰ってほしい。
これは、LLMから直接と言う意味であれば、個人的にはNOだと思う。
ただし、LLMに指示すればバイナリが出力されるという意味であれば、個人的にはYESと答える。
この二つは明確に異なるので、今後自分の意見を述べる際には区別すると良いと思う。
コーディング周りの環境が劇的に整備されつつある、という話題に軽く触れたのはこのためで、LLMが直接バイナリを出力しなくても、結果が同じであれば人々はそれほど気にしない。
例えば、現時点でもローカルのLLMに指示するとGO言語で書かれたコードが生成され、ローカル環境に合わせたシングルバイナリが出力される一連のパイプラインを組むことはできる。
自分の想定する、未来のAIがバイナリを直接出力するというのは、この延長にあると思う。AIがイコールLLMである必要はどこにもない。
少しでもクラウド上でのサーバー処理について触れると、廃棄容易性(Disposability)は俎上に上がる。いつでも落とせていつでも捨てられる、という性質のことである。
こうした、単機能バイナリをコンテナ等に載せて処理し、日に数度デプロイするような環境だと、LLMがバイナリを出力するというのもそれほど遠い未来の話には思えなくなる。
LLMが機械語を出力する未来は個人的には来ないと思う。それは難易度が高いからではなく単純にメリットが少ないからである。
ただし、パイプラインが組まれた一環として、LLMがバイナリを出力する未来は、それほど不思議には思わない。現時点でも可能である。
単純なLinterから進んで静的解析や、動的な結合試験が組み込まれているCICDパイプラインが珍しいとまでは言えない現代において、来るべき近未来像としては妥当性がある。
（その場合、ソースコードはログとして機能し、テキストで保管が容易な、次回以降変更可能なコンテキストの一部になるだろうと思う。今後変更不要ならHDLでFPGAを弄った方が早い）
現代人のすべてがJavaで同一の書き方をしているのではない現状において、自然言語では揺らぎが強すぎて形式言語ほど意図を機械に伝えきれないという反論は、弱い。
それよりは、現代のLLMはコンテキストウィンドウが人間の数倍～数十倍程度で、適切に分割して処理しなければならず、大規模なソフトウェアを丸ごと扱えるほどではない、という反論の方が適切である。
ただ、LLMに適したプログラミング言語が生まれるのではないかと言う予測には懐疑的である。既存のプログラミング言語を使う方が人間が読みやすい。
AIが、人間が欲しいバイナリに適したプログラミング言語をLLMを用いて書き、LLMを用いてレビューし、テストツールでテストし、コンパイラでビルドし、ツールでデプロイし、実稼働するという未来予想図が、荒唐無稽とは思えない。
LLMに適したプログラミング言語が生まれる未来よりも、(冗長であっても)人間可読性の高いコードやSelf-documenting codeが生成される未来の方が、来そうに思う。
また、おそらくこの文章のもつくであろう「どんなプロンプトで書いたのか」という、一定以上の長さの文章はLLMが出力しただろうと仮定する人間が増えている(そしてある程度の妥当性がある)現状において、プロンプトで指示してデプロイまでされる未来はそこまで遠いとも思えない。
ただ、購入できるハードウェアの性能とコストが律速になるので、よほど特殊な(CPUやGPUの設計をLLMが劇的に改善する)状況にならない限り、5～10年はプログラマーが消えることは無いと思う。
金に糸目をつけないのであれば、再来年当たりからはLLMレビューのみで仕様バグ以外のほぼ無いプロダクトが世に出てもおかしくは無いと思う。
そもそもこんなの何十年もやり尽くされたトピックで心理学じゃ常識なんだよね
調べればすぐに出るはず
それを「無能な女」だからわからないというのがダメなところでIQの問題ではない
IQは普通にあれば誰でもできることであって知的なトレーニングの問題
• Irwing ＆Lynn (2005) –Sex differences in means and variabilityonRaven’sProgressive Matrices
https://doi.org/10.1348/000712605X53542
•Hyde (2005) – Thegender similarities hypothesis
https://doi.org/10.1037/0003-066X.60.6.581
• Machin ＆ Pekkarinen (2008) – Globalsex differences intestscore variability (Science)
https://www.science.org/doi/10.1126/science.1162573
• Deary (2012) –Sex differences inintelligence (Cambridge Handbook ofIntelligence)
• Halpernet al. (2007) – Males and females have the same distribution ofIQscores
と質問とした所、
いい質問。ただ、**今回私が提示したC#コード（MemoryMappedFile + Parallel.For でCR を数える）**には、明確に一つの「このネット上の記事／リポジトリをそのままコピーした」元ネタはありません。
いくつか似たアイデアを使ってる部分と参考になる記事／ドキュメントはあるので、それらを紹介します：
---
*Microsoftドキュメント — Memory-Mapped Files (.NET)*
([Microsoft Learn][1])
*Kieren Johnstone: 高速に MemoryMappedFileからバイト列を読む方法（StackOverflow）*
`MemoryMappedViewAccessor` を使って unsafeコードからポインタを取得し、Marshal.Copy で効率よく読み出す方法。
([StackOverflow][2])
*Red-Gate: Sharingis Caring: Using Memory Mapped Files in .NET*
MemoryMappedFile を使ったキャッシングなどの応用。
*Stephen Cleary のブログ: Memory-Mapped Files と Overlaid Structs*
メモリマップトファイルへ構造体を重ねて（オーバーレイ）扱う方法など。
([blog.stephencleary.com][4])
---
もしよければ、**あなたのコード（CR を数えるもの）に特化した元ネタをさらに探してみます**。やりましょうか？
[1]:https://learn.microsoft.com/en-us/dotnet/standard/io/memory-mapped-files?utm_source=chatgpt.com "Memory-Mapped Files - .NET"
[2]:https://stackoverflow.com/questions/7956167/how-can-i-quickly-read-bytes-from-a-memory-mapped-file-in-net?utm_source=chatgpt.com "How can I quickly read bytes from a memory mapped file in ..."
[3]:https://www.red-gate.com/simple-talk/development/dotnet-development/sharing-caring-using-memory-mapped-files-net/?utm_source=chatgpt.com "Sharingis Caring: Using Memory Mapped Files in .NET"
[4]:https://blog.stephencleary.com/2023/09/memory-mapped-files-overlaid-structs.html?utm_source=chatgpt.com "Memory-Mapped Files and Overlaid Structs"
ChatGPT:
が、出てきて、やってくれと言ったら、こういうのが出てきた。
了解しました — 広く（英語・日本語・GitHub・ブログ・StackOverflow 等）再検索しました。結論と見つかった“近い”ソースをまとめます。
結論（要点）**
「あなたが求めている**MemoryMappedFile を使い、UTF-8バイナリ中の `CR`（0x0D）だけを数える・マルチスレッドで分割して処理する**」という **完全一致の“元ネタ”ソースコード**は、公開されたweb 上のリポジトリや記事の中では見つかりませんでした（複数の検索ワード／検索対象で確認）。([hyr.mn][1])
ただし、ほぼ同種の要素（メモリマップドファイルの読み方・大きなファイルの行数カウント・バイト単位カウントを高速化する手法）は複数見つかりました。これらを組み合わせれば、先に示した実装は典型的なパターンであることが確認できます。([Microsoft Learn][2])
見つかった“近い”・参考になりそうなソース（抜粋）**
1. .NET の公式ドキュメント（MemoryMappedFile の説明） — `MemoryMappedFile` の基本とCreateViewStream /CreateViewAccessor の使い方。必須の参照。([Microsoft Learn][2])
2. 「Countinglines withC#」というブログ記事（C# で改行（CR/LF）カウントに関する実装とGitHubリンク） — 行数カウントを目的とした実装パターンがある。([hyr.mn][1])
3. StackOverflow：MemoryMappedFileから高速にバイトを読む方法（`MemoryMappedViewAccessor` / unsafeポインタ / Marshal.Copy 等の議論） — 高速実装のヒント。([StackOverflow][3])
4. StackOverflow／Q&A：ファイル中のLF/CR の数を求める方法に関するスレッド（`grep -c $'\r'` 等のunix 例やC# でのカウント方法の議論）。([StackOverflow][4])
5.GitHub のサンプルリポジトリ（MemoryMappedFile のテスト／サンプル） —メモリマップドファイルを使う実装例。([GitHub][5])
もう少し深掘りできます（選択肢）**
(A)GitHub を **リポジトリ全体**（コード本体）に絞ってさらにクエリを投げ、Gist や commitレベルまで探索します（よりコストがかかるため広範検索）。
(B)ブログ・技術記事を対象に **全文一致（コード断片）検索** を行い、私が先に示したC#コードの実際の一節（たとえば `mmf.CreateViewStream(offset, size)` や `Interlocked.Add(ref totalCount, localCount)` など）を直接検索して完全一致を探します。
(C) 「オリジナルはGitHub にあるはず」と思われるなら、あなたが覚えている**リポジトリ名の断片／作者名／投稿日**などを教えていただければ、それを手がかりに探します（断片情報があるとヒット率がぐっと上がります）。
どれを優先して探しましょうか？（A:GitHub全探査 / B:コード断片で全文検索 / C:あなたからヒント提供）
※続けて深掘りする場合は、すぐにさらに広い検索を行って該当ソースを探します（そのまま実行します）。
[1]:https://hyr.mn/catching-flowers-with-a-net?utm_source=chatgpt.com "Countinglines withC# - hyr.mn"
[2]:https://learn.microsoft.com/en-us/dotnet/standard/io/memory-mapped-files?utm_source=chatgpt.com "Memory-Mapped Files - .NET"
[3]:https://stackoverflow.com/questions/7956167/how-can-i-quickly-read-bytes-from-a-memory-mapped-file-in-net?utm_source=chatgpt.com "How can I quickly read bytes from a memory mapped file in ..."
[4]:https://stackoverflow.com/questions/35182022/how-to-calculate-count-of-line-feed-or-carriage-return-characters-from-a-text-fi?utm_source=chatgpt.com "How to calculate count ofline feed or carriage return ..."
[5]:https://github.com/byGeek/MemoryMappedFileTest?utm_source=chatgpt.com "test csharp code for using memory mapped file."
