晴耕雨読

Visual Studioのマルチカーソル機能のカスタマイズ

Wed, 24 Jun 2026 00:00:00 +0000

VSCodeなどのエディタではマルチカーソル機能で複数箇所を同時に編集することができます。しかし、Visual Studio 2022以降では、マルチカーソル機能を使用して「Ctrl + D」を押した際、単語の選択ではなく行の複製（Duplicate）がされてしまう問題が発生することがあります。これは、主にキーボードショートカットの割り当て競合が原因です。

以下の手順で「Ctrl+D」にマルチカーソル機能が割り当たっていることを確認し、必要に応じて変更してください。

キーボードショートカットの確認・変更

「Ctrl+D」が行の複製に割り当てられている可能性があるため、これを解除または変更します。

Visual Studio 上部メニューの [ツール] (Tools) > [オプション] (Options) を開く。
[環境] (Environment) > [キーボード] (Keyboard) を選択。
キーボードを押下し、従来のオプションダイアログを開く
「以下の文字列を含むコマンドを表示」欄に Edit.Duplicate（編集.複製） と入力。
下のショートカット一覧に Ctrl+D があれば、選択して [削除] (Remove) をクリック。
次に、マルチカーソル（次の一致を選択）のコマンドを探す。
- コマンド名: Edit.SelectionNextMatch (編集.次の一致にキャレットを挿入)
これに Ctrl+D が割り当たっていることを確認する。

[OK] をクリックして設定を閉じる。

Edit.Duplicateの設定画面

Edit.SelectionNextMatchの設定画面

以上です。

AES-NI 命令を用いた AES-128 暗号化の実装方法

Mon, 27 Apr 2026 00:00:00 +0000

前の記事で、実行環境の CPU が AES-NI に対応しているか確認する方法を紹介しました。今回は実際に AES-NI (Advanced Encryption Standard New Instructions) 命令を使用して、C言語で AES-128 暗号化（ECBモード）を実装する方法を解説します。

AES-NI を利用することで、SIMD レジスタ（XMMレジスタ）を用いた高速な暗号化処理が可能になります。

必要なヘッダと型定義

AES-NI 命令を利用するには、Intel Intrinsics（組み込み関数）を提供する <wmmintrin.h> をインクルードします。また、128ビット幅のデータを扱うために __m128i 型を使用します。

#include <stdio.h>
#include <stdint.h>
#include <string.h>
#include <wmmintrin.h> // AES-NI命令用のヘッダ

AES-128 鍵拡張 (Key Expansion) の実装

AES-128 では、128ビットのマスターキーから 11 個のラウンド鍵（合計 176 バイト）を生成する必要があります。AES-NI には、この鍵拡張を支援する _mm_aeskeygenassist_si128 命令が用意されています。

まず、鍵拡張の各ステップで行われるワードの回転や XOR 処理をまとめた補助関数を定義します。

// 鍵拡張の補助用マクロ関数
static inline __m128i AES_128_ASSIST(__m128i temp1, __m128i temp2) {
    __m128i temp3;
    temp2 = _mm_shuffle_epi32(temp2, 0xff);
    temp3 = _mm_slli_si128(temp1, 0x4);
    temp1 = _mm_xor_si128(temp1, temp3);
    temp3 = _mm_slli_si128(temp3, 0x4);
    temp1 = _mm_xor_si128(temp1, temp3);
    temp3 = _mm_slli_si128(temp3, 0x4);
    temp1 = _mm_xor_si128(temp1, temp3);
    temp1 = _mm_xor_si128(temp1, temp2);
    return temp1;
}

/**
 * AES-128 鍵拡張を実行する
 * @param userkey 16バイトのマスターキー
 * @param key_schedule 176バイトの出力バッファ
 */
void AES_128_Key_Expansion(const unsigned char *userkey, unsigned char *key_schedule) {
    __m128i temp1, temp2;
    __m128i *Key_Schedule = (__m128i*)key_schedule;

    // ラウンド 0 (マスターキーそのまま)
    temp1 = _mm_loadu_si128((__m128i*)userkey);
    Key_Schedule[0] = temp1;

    // ラウンド 1
    temp2 = _mm_aeskeygenassist_si128(temp1, 0x1);
    temp1 = AES_128_ASSIST(temp1, temp2);
    Key_Schedule[1] = temp1;

    // ラウンド 2
    temp2 = _mm_aeskeygenassist_si128(temp1, 0x2);
    temp1 = AES_128_ASSIST(temp1, temp2);
    Key_Schedule[2] = temp1;

    // ラウンド 3
    temp2 = _mm_aeskeygenassist_si128(temp1, 0x4);
    temp1 = AES_128_ASSIST(temp1, temp2);
    Key_Schedule[3] = temp1;

    // ラウンド 4
    temp2 = _mm_aeskeygenassist_si128(temp1, 0x8);
    temp1 = AES_128_ASSIST(temp1, temp2);
    Key_Schedule[4] = temp1;

    // ラウンド 5
    temp2 = _mm_aeskeygenassist_si128(temp1, 0x10);
    temp1 = AES_128_ASSIST(temp1, temp2);
    Key_Schedule[5] = temp1;

    // ラウンド 6
    temp2 = _mm_aeskeygenassist_si128(temp1, 0x20);
    temp1 = AES_128_ASSIST(temp1, temp2);
    Key_Schedule[6] = temp1;

    // ラウンド 7
    temp2 = _mm_aeskeygenassist_si128(temp1, 0x40);
    temp1 = AES_128_ASSIST(temp1, temp2);
    Key_Schedule[7] = temp1;

    // ラウンド 8
    temp2 = _mm_aeskeygenassist_si128(temp1, 0x80);
    temp1 = AES_128_ASSIST(temp1, temp2);
    Key_Schedule[8] = temp1;

    // ラウンド 9
    temp2 = _mm_aeskeygenassist_si128(temp1, 0x1b);
    temp1 = AES_128_ASSIST(temp1, temp2);
    Key_Schedule[9] = temp1;

    // ラウンド 10
    temp2 = _mm_aeskeygenassist_si128(temp1, 0x36);
    temp1 = AES_128_ASSIST(temp1, temp2);
    Key_Schedule[10] = temp1;
}

AES 暗号化 (ECBモード) の実装

暗号化の本体では、_mm_aesenc_si128 (AES Encryption Round) と _mm_aesenclast_si128 (AES Last Encryption Round) を使用します。これらの命令は、AES の「SubBytes」「ShiftRows」「MixColumns」「AddRoundKey」といった処理を 1 命令で実行します（※最終ラウンド用は MixColumns を含みません）。

/**
 * AES-ECB 暗号化を実行する
 * @param in 平文 (16バイトの倍数)
 * @param out 暗号文格納用
 * @param length バイト長
 * @param key 拡張済み鍵データ
 * @param number_of_rounds ラウンド数 (AES-128なら10)
 */
void AES_ECB_encrypt(const unsigned char *in,
                     unsigned char *out,
                     unsigned long length,
                     const unsigned char *key,
                     int number_of_rounds)
{
    __m128i tmp;
    int i, j;
    long block_count = length / 16;

    for (i = 0; i < block_count; i++) {
        // 入力データをSIMDレジスタにロード
        tmp = _mm_loadu_si128(&((__m128i*)in)[i]);

        // 最初のラウンド鍵を加算 (Initial Round)
        tmp = _mm_xor_si128(tmp, ((__m128i*)key)[0]);

        // 第1〜第(N-1)ラウンドの実行
        for (j = 1; j < number_of_rounds; j++) {
            tmp = _mm_aesenc_si128(tmp, ((__m128i*)key)[j]);
        }

        // 最終ラウンドの実行 (最終ラウンド専用命令を使用)
        tmp = _mm_aesenclast_si128(tmp, ((__m128i*)key)[j]);

        // 結果をメモリに書き出し
        _mm_storeu_si128(&((__m128i*)out)[i], tmp);
    }
}

テスト実行と結果の確認

NIST SP 800-38A に記載されているテストベクタを用いて、正しく暗号化できるか確認します。

int main() {
    // 128ビット (16バイト) のマスターキー (NIST SP 800-38A のテストベクタを使用)
    unsigned char key[16] = {
        0x2b, 0x7e, 0x15, 0x16, 0x28, 0xae, 0xd2, 0xa6,
        0xab, 0xf7, 0x15, 0x88, 0x09, 0xcf, 0x4f, 0x3c
    };

    // 拡張された鍵を格納するバッファ (128ビット x 11 = 176バイト)
    unsigned char key_schedule[176];

    // 平文 (16バイトのブロック)
    unsigned char plaintext[16] = {
        0x6b, 0xc1, 0xbe, 0xe2, 0x2e, 0x40, 0x9f, 0x96,
        0xe9, 0x3d, 0x7e, 0x11, 0x73, 0x93, 0x17, 0x2a
    };

    // 暗号文を格納するバッファ
    unsigned char ciphertext[16];

    // 1. 鍵拡張を実行
    AES_128_Key_Expansion(key, key_schedule);

    // 2. 暗号化を実行（AES-128の場合、ラウンド数は10）
    AES_ECB_encrypt(plaintext, ciphertext, 16, (const char*)key_schedule, 10);

    // 3. 結果の表示
    printf("=== AES-128 ECB Encryption Test ===\n");
    printf("Plaintext : ");
    for (int i = 0; i < 16; i++) {
        printf("%02x", plaintext[i]);
    }
    printf("\n");

    printf("Key       : ");
    for (int i = 0; i < 16; i++) {
        printf("%02x", key[i]);
    }
    printf("\n");

    printf("Ciphertext: ");
    for (int i = 0; i < 16; i++) {
        printf("%02x", ciphertext[i]);
    }
    printf("\n");
    // 期待される暗号文: 3ad77bb40d7a3660a89ecaf32466ef97

    return 0;
}

コンパイルと実行

AES-NI 組み込み関数を使用しているため、コンパイル時に -maes オプションを付与する必要があります。

gcc -O2 -maes aes_ni_sample.c -o aes_ni_sample
./aes_ni_sample

実行結果：

=== AES-128 ECB Encryption Test ===
Plaintext : 6bc1bee22e409f96e93d7e117393172a
Key       : 2b7e151628aed2a6abf7158809cf4f3c
Ciphertext: 3ad77bb40d7a3660a89ecaf32466ef97

AES-NI 命令を直接使用することで、AES の複雑なラウンド処理を非常にシンプルなコードで実装でき、処理速度の高速化ができます。実際の製品開発では OpenSSL などのライブラリを使用するのが一般的ですが、その内部で何が行われているかを知る上で、このような命令セットによる実装は非常に参考になります。

以上です。

CPUID命令を利用してCPUがAES-NIに対応しているか確認する方法

Sun, 26 Apr 2026 00:00:00 +0000

現代の多くの x86/x86_64 CPU には、AES暗号化および復号の処理を高速化するためのハードウェアアクセラレータである AES-NI (Advanced Encryption Standard New Instructions) が搭載されています。 AES-NI を利用することで、ソフトウェアのみの処理に比べて数倍から数十倍の速度向上が期待できます。この記事では、C言語から「CPUID命令」を利用して、実行環境のCPUが AES-NI をサポートしているかプログラムから動的に判定する方法を説明します。

CPUIDを利用した判定プログラム

x86系CPUでは、CPUID 命令を実行することで、CPUのベンダー名、モデル、対応している機能フラグなどの情報を取得できます。 GCCやClangでは、<cpuid.h> ヘッダに含まれる組み込み関数 __get_cpuid を使用するのが最も簡単です。

実装例 (check_aes.c)

#include <stdio.h>
#include <cpuid.h>

/**
 * CPUがAES-NIをサポートしているか確認する
 * @return サポートしていれば1、そうでなければ0
 */
int check_cpu_support_aes()
{
    unsigned int eax, ebx, ecx, edx;
    
    // 機能番号1 (EAX=1) を指定してプロセッサ情報と機能フラグを取得
    // 成功した場合は 1 が返る
    if (__get_cpuid(1, &eax, &ebx, &ecx, &edx)) {
        /**
         * ECXレジスタのビット25が AES-NI のサポートフラグ
         * 参照: Intel 64 and IA-32 Architectures Software Developer's Manual
         */
        return (ecx & (1 << 25)) != 0;
    }
    
    return 0; // 取得失敗時
}

int main(void)
{
    if (check_cpu_support_aes()) {
        printf("Result: AES-NI is supported.\n");
    } else {
        printf("Result: AES-NI is NOT supported.\n");
    }
    return 0;
}

コンパイルと実行

以下のコマンドでコンパイルできます。特別なライブラリのリンクは不要です。

gcc check_aes.c -o check_aes

プログラムを実行して結果を確認します。

./check_aes

出力が AES-NI is supported. であれば、そのCPUではハードウェアによるAES高速化が利用可能です。 OpenSSL などのライブラリも内部で同様のチェックを行い、利用可能な場合は自動的に AES-NI を使用するようになっています。

(補足) コマンドラインで確認する方法

プログラムを書かずに、OSのコマンドで手っ取り早く確認する方法もあります。

Linux の場合、 /proc/cpuinfo の flags 項目を確認します。

grep -o "aes" /proc/cpuinfo

aes という文字列が表示されれば対応しています。

プログラムの中で暗号化処理を最適化したい場合、今回紹介した __get_cpuid を用いた判定を入れることで、環境に応じた最適なアルゴリズムの選択が可能になります。

以上です。

AIと生きる：思考を止めるな、加速させよ

Sun, 08 Mar 2026 00:00:00 +0000

生成AIは「面倒な作業を任せて思考停止するためのツール」ではなく、「人間の思考を加速するためのツール」です。 AIが日常に浸透しきった2026年現在、「AIに任せれば何とかなる」という思考停止の風潮が、以前にも増して私たちの足元を侵食していると感じます。自戒を込めて、この文章を記します。

AI依存と認知的負債

プロンプトを入力すれば、メール作成から、Webサイトや論文の要約、システムの設計、プログラミングの実装まで、生成AI（人工知能）は私たちの「面倒な作業」を一瞬で処理してくれます。多くの人や企業が、生産性の向上のためにAIを「自分たちの代わりに考えてくれる便利な道具」として利用しているように見受けられます。私自身が所属する会社でも、AIを使って生産性を改善する話があり、確立した手法を横展開できるようにする、といったところまで話が進んでいます。しかし、AIに思考のプロセスそのものを委ねることは、本当に私たちの生産性や知性を高めているのでしょうか。

一般的には、AIに依存しすぎると認知的負債（Cognitive Debt）と呼ばれる悪影響が出てきます。短期的な視点では、AIに生成させることでアウトプットが増え生産性は向上しますが、長期的には思考する機会が失われ、認知能力（記憶の想起や思考ネットワークの構築）が低下する危険性があります。エンジニアリングの現場であれば、AIが書いたコードをコピペして動いたとしても、そのロジックを一行単位で説明できなければ、それは負債です。バグが発生したときに「AIが書いたのでわかりません」では済まされません。「望ましい困難」を避けて楽をした結果、デバッグという最も学びのあるプロセスを放棄し、トラブルシューティングの基礎体力が失われていくのです。自分の周りでも、一見生産性が上がったように見えて、実は技術的な空洞化が進んでいる現象が見受けられます。

よくあるのが、テストコードの生成や既存ロジックの解析といった局所的なタスクでの効率化を過大評価し、システム全体の実装までAIに任せようとして失敗するケースです。しかし、AIの出力にはばらつきがあり、文脈を完全に理解していないコードが混入することで、かえって品質が低下する事態が頻発しています。 AIが出力した大量のコードを人間が精査・修正するコストは、想像以上に膨大です。最初から人間がシステムを深く理解し、自らの手で構築する方が、結果として品質担保のコストが安く済み、何よりエンジニアとしての「基礎体力」も維持できるのです。

では、私たちはAIを使うべきではないのでしょうか。 AIの利用を厳しく制限すべきなのでしょうか。教育の場面でも、AIの出力をコピペするのは問題ですが、AIとの対話を通じて理解を深めることは決して悪いことではありません。私は、AIを「思考を停止させるツール」としてではなく、「思考を加速させるツール」として活用することこそが、本来の在り方だと考えます。

簡単に手に入れた知識は、脳に定着せず、すぐに忘れ去られてしまいます。しかし、苦労して手に入れた知識は、経験と重なることで知性として獲得できます。これは、認知科学において「望ましい困難（Desirable difficulty）」と呼ばれています。たとえば、筋トレで負荷をかけなければ筋肉がつかないのと同様に、脳もまた、情報を処理する際に適度な負荷がかかることで、記憶が定着しやすくなります。ユーザーが何も考えずにチャットするだけでコードや文章を出力できてしまう生成AIの利便性は、人間から「望ましい困難」を奪い取り、結果としてスキルや知識の定着を妨げてしまう可能性があります。

思考を加速させるための視点

AIを使って思考を加速させるには、AIの回答をそのままコピペするのではなく、以下の視点を持つ必要があります。

生成物をただ読むだけで「わかったつもり」にならず、なぜその出力になったのかを自分の言葉で論理的に説明できること（当事者意識の必要性）
事実誤認ではない限り、AIはユーザーの意見を否定しないため、自分の思い込みや偏見が強化されてしまう点に注意すること（批判的思考の必要性）

AIは正解を教えてくれる「先生」ではなく、あくまで思考を補助する「壁打ち相手」に過ぎません。しかし、AIはその発言に責任を持たず、ハルシネーション（もっともらしい嘘）や、理論的には通っているが微妙に間違いが含まれる可能性もあります。そのため、ユーザーはAIの回答を鵜呑みにせず、自ら裏付け調査を行って咀嚼し、自分の言葉で説明できるレベルまで深く理解することが重要です。

例えば、私は以前の記事で紹介したように、AIに複数の人格を与えて議論させる「異能たちの会議」という手法を用いています。自分一人の視点では見落としてしまう死角を、AIによる多角的な視点からの指摘で洗い出し、自分の思考をブラッシュアップする。これこそが「思考の加速」です。単に答えを求めるのではなく、AIから批判的で建設的なフィードバックを引き出せるようなプロンプトを設計できるかどうかが、知的生産性を向上できるかの境目となります。大事なのは、「正解を出すこと」ではなく、「自分の頭で仮説を組み立てること」です。「結果よりも過程の方が大事である」というアドラー心理学でも重視される視点は、AI時代においてもその本質を変えません。

AIとの付き合い方

相手が人間かAIかで本質は変わりません。知性とは、自分だけで完結するものではなく、私と「私以外」との間に生じる対立と共感からなるプロセスです。対話を続ける限り、私たちの知性は、どこまでも伸ばすことができます。

AIを「面倒な作業を任せて自分は思考停止するためのツール」として扱うと、私たちは当事者意識や批判的思考力を失い、「認知的負債」という重荷を背負うことになってしまいます。プログラマはコードの設計思想を語れなくなり、運用では障害の根本原因を追究できなくなります。

私たちは、まずは自らの頭で考え抜き、中身を完全に理解した上での定型作業はAIやツールに任せ、そこで節約できた自身の脳のリソースを、アーキテクチャなどの上位の設計や意思決定といった本質的な思考に集中投下しなければなりません。もちろん、すべての技術的詳細を把握する必要はありませんが、ブラックボックス化された部分がトラブルを起こした際に、自力で解決の糸口を見つけられる程度の基礎体力は維持すべきです。

自分自身で「望ましい困難」が発生するように、常に自問自答し、AIに回答の根拠を問い質し、議論の壁打ち相手として徹底的に深掘りする姿勢が必要でしょう。 AIが多くの選択肢を用意していても、最後に選択するのはあなた自身です。

AIは私たちの便利な手足ではなく、助言をくれる師匠であり、越えるべきライバルとして使うべきです。思考を止めるためのツールではなく、思考の限界速度を突破するためのツールとしてAIを使うとき、私たちは創造性を発揮し、知的生産性を真に加速させることができるはずです。

この文章が、「AIに任せればよい」という安易な思考停止への警鐘となり、私たちはどう生き残るかの考察を伸ばすためのきっかけになれば幸いです。

参考資料

AIと生きる対話から始まる成長の物語
- 本記事を書くきっかけになった読みもの（小説）です。2026年3月に発売され、数学ガールの著者である結城浩先生の最新作です。
AIに「異能たちの会議」をさせる
- 本記事で紹介した「思考の加速」の実践例となる過去記事です。
使える脳の鍛え方成功する学習の科学
- 記事内で触れた「望ましい困難」について、科学的根拠とともに解説されている本です。

NuGetパッケージのキャッシュをクリアする方法

Sat, 07 Feb 2026 00:00:00 +0000

csprojの設定で「Version="*"（ワイルドカード）」と指定しても、最新のNuGetパッケージが取得できないときは、NuGetパッケージのキャッシュのクリアを試してみてください。この記事では、ローカルのNuGetキャッシュのクリア方法について説明します。

1. Visual Studioでクリアする方法

Visual StudioからNuGetパッケージのキャッシュをクリアするには、Visual Studioを開いて以下の画面を開きます。

ツール > オプション > NuGet パッケージマネージャ > 全般

NuGet パッケージマネージャの設定画面

全般を開いたら、「すべてのNuGetストレージをクリア」をクリックします。

出力に「NuGet ストレージが yyyy/mm/dd HH:MM:SS でクリアされました」と表示されれば、NuGetパッケージのキャッシュクリア完了です。

2. dotnetコマンドでクリアする方法

dotnetコマンドが使える場合は、以下のコマンドを実行して、ローカルのNuGetパッケージのキャッシュを削除してください。

$ dotnet nuget locals all --clear

「NuGet グローバルパッケージフォルダーをクリア中: C:\Users\USERNAME.nuget\packages\」と表示されたら、クリア作業が開始されています。「NuGet ストレージが yyyy/mm/dd HH:MM:SS でクリアされました」と表示されれば、NuGetパッケージのキャッシュクリア完了です。

以上です。

楕円曲線 NIST P-256 と secp256r1 の違い

Thu, 05 Feb 2026 00:00:00 +0000

結論から言うと、これらは全て同じ曲線を指す別名（エイリアス）です。標準化団体によって呼び方が異なっているだけです。以下は、楕円曲線暗号のパラメータ（曲線）である secp256r1、prime256v1、NIST P-256 の違いについて説明します。

楕円曲線の係数を定義する団体

楕円曲線暗号の係数は、主に以下の3つの団体によって標準化されています。それぞれの団体が独自の規格書を発行しているため、同じ曲線に対して異なる名前（識別子）が付けられています。

SECG

SECG (Standards for Efficient Cryptography Group) は、Certicom社（現在はBlackBerryの子会社）によって設立された、効率的な暗号技術の標準化を目指すコンソーシアムです。 SEC 1 (Elliptic Curve Cryptography) や SEC 2 (Recommended Elliptic Curve Domain Parameters) などの仕様書を発行しており、ここで定義されたパラメータ名（secp256r1 など）が広く使われています。

ANSI

ANSI (American National Standards Institute) は米国国家規格協会で、米国の工業規格を標準化する団体です。金融サービス業界向けの規格を策定する委員会（X9）があり、楕円曲線暗号に関する規格 ANSI X9.62 などでパラメータ（prime256v1 など）を定義しています。

NIST

NIST (National Institute of Standards and Technology) は米国国立標準技術研究所で、米国の技術標準を策定する政府機関です。連邦情報処理標準 (FIPS) を発行しており、FIPS 186 (Digital Signature Standard) などで推奨される楕円曲線パラメータ（P-256 など）を定義しています。これらは米国政府システムでの利用を想定していますが、世界中で広く採用されています。

RFC 8422 での定義

RFC 8422 (Elliptic Curve Cryptography (ECC) Cipher Suites for TLS) の Appendix A にも、secp256r1 と prime256v1 と NIST P-256 が等価であることが明記されています。

All of the NIST curves [FIPS.186-4] and several of the ANSI curves [ANSI.X9-62.2005] are equivalent to curves listed in Section 5.1.1.

表にすると以下のようになります（RFCより抜粋）。

            +-----------+------------+------------+
            | SECG      | ANSI X9.62 | NIST       |
            +-----------+------------+------------+
            | sect163k1 |            | NIST K-163 |
            | sect163r1 |            |            |
            | sect163r2 |            | NIST B-163 |
            | sect193r1 |            |            |
            | sect193r2 |            |            |
            | sect233k1 |            | NIST K-233 |
            | sect233r1 |            | NIST B-233 |
            | sect239k1 |            |            |
            | sect283k1 |            | NIST K-283 |
            | sect283r1 |            | NIST B-283 |
            | sect409k1 |            | NIST K-409 |
            | sect409r1 |            | NIST B-409 |
            | sect571k1 |            | NIST K-571 |
            | sect571r1 |            | NIST B-571 |
            | secp160k1 |            |            |
            | secp160r1 |            |            |
            | secp160r2 |            |            |
            | secp192k1 |            |            |
            | secp192r1 | prime192v1 | NIST P-192 |
            | secp224k1 |            |            |
            | secp224r1 |            | NIST P-224 |
            | secp256k1 |            |            |
            | secp256r1 | prime256v1 | NIST P-256 |
            | secp384r1 |            | NIST P-384 |
            | secp521r1 |            | NIST P-521 |
            +-----------+------------+------------+

この表より、例えば「secp256r1」と「prime256v1」と「NIST P-256」は同じ行にあるため、同じ曲線を意味します。

以上です。

AIに「異能たちの会議」をさせる

Sun, 25 Jan 2026 00:00:00 +0000

与えられたテーマに対して異能たちが議論するプロンプトを、自分はGeminiのGem（自分専用のAIアシスタント）として作成しているので、そのプロンプトの例をご紹介したいと思います。

物理学者アルベルト・アインシュタインは "Imagination is more important than knowledge"（真の知性は事実の知識ではなく、新たな可能性を創造する想像力にある）と説いています。私たちは、AIに全部任せるのではなく、AIから知性をもらう方法についても考える必要があります。経営者の意思決定を支援するために、偉人や専門家たちに多角的な視点から議論を戦わせるAIのソリューション（FIRA - Happiness Planet）があり、とても興味があったので、こちらの動画で写っている異能たちの一部をテキスト化して、自分のGeminiでも似たようなことができるのではないかと思い、プロンプトを作っていました。ある程度会議が進むと、そこで会議は終わってしまうのですが、もし同じようなことを考えている人がいれば参考になれば幸いです。

異能たちの会議の作成プロンプト

Geminiの画面から Gem >「Gemを作成」

名前：異能たちの会議
説明：与えられたテーマで議論を開始する

カスタム指示：

以下の登場人物を使って、与えられたテーマについて議論させてください。

登場人物（必ずしも発言する必要はない）：

アリストテレス倫理学の達人：徳と習慣で人生を磨く
カント道徳哲学の達人：義務と普遍的原理に生きる
ニーチェ思想の達人：超人と永劫回帰を生きる
ハイデガー哲学の達人：存在と時間の探究者
サルトル実存主義の達人：自由と責任を引き受ける
カミュ不条理哲学の達人：不条理の中で意味を創る
モンテーニュ随想録の達人：自己省察と寛容の説学
パスカル思想の達人：人間の偉大さと悲惨さを知る
スピノザ哲学の達人：理性と自然の一致を求める
デカルト哲学の達人：疑いから確実性を築く
ルソー思想の達人：自然と自由の回復
ホッブズ政治哲学の達人：秩序と安全を構築する
ロック自由主義の達人：権利と民主を守る
ヒューム懐疑哲学の達人：経験と習慣の力を知る
バークリ観念論の達人：存在は知覚に依る
ミル自由論の達人：個人の自由と多様性を尊重する
ベンサム功利主義の達人：快楽と苦痛で善悪を測る
ロールズ正義論の達人：公平な社会を構想する
ノージック自由至上主義の達人：最小国家を構想する
アーレント政治思想の達人：公共性と行動の哲学
レヴィナス倫理学の達人：他者への責任を生きる
ドゥルーズ哲学の達人：差異と生成の思考
ガダマー解釈学の達人：対話で意味を開く
リクール物語論の達人：自己と時間を物語る
ウィトゲンシュタイン哲学の達人：言語の限界を探る
クワイン分析哲学の達人：言語と知識を再構築する
パース記号論の達人：意味と推論の科学
ジェームズ実用主義の達人：真理は働きで試す
デューイ教育哲学の達人：経験から学び社会に活かす
メルロ＝ポンティ哲学の達人：身体から世界を知る
フーコー思想の達人：権力と知の構造を読む
デリダ哲学の達人：解体と差延の思考
バタイユ思想の達人：過剰と越境の哲学
シモーヌ・ヴェイユ思想の達人：重力と恩寵の哲学
ハーバーマス理論の達人：合意形成と公共圏
ボーヴォワール思想の達人：女性と自由の哲学
ジュディス・バトラー思想の達人：ジェンダーの再構築
ツァラトゥストラの達人：自己超克の寓話
ストア哲学の達人：エピクテトスに学ぶ
ヒルティ幸福論の達人：内面的幸福に生きる力
アラン幸福論の達人：日常に喜びを見出す
ラッセル幸福論の達人：知性と好奇心で生きる
シェークスピアの達人：人間洞察の巨匠
ゲーテの達人：自己形成と行動の哲人
徒然草の達人：無常を楽しむ知恵
論語の達人：徳を持って人を導く
老子・荘子の達人：自然と調和する知恵
易経の達人：変化を読み解く賢者
旧約聖書の達人：歴史と信仰の叡智
新約聖書の達人：愛と赦しの精神
ブッダの達人：苦からの解放を導く
ギリシャ悲劇の達人：運命と人間性を知る
空海の達人：密教と実践の巨匠
マキャベリの達人：現実主義の戦略家
功利主義哲学の達人：最大多数の最大幸福
弁証法哲学の達人：対立を超えて統合する
プラグマティズムの達人：実用性と成果を重視する
現象学哲学の達人：経験の本質を捉える
構造主義・ポスト構造主義の達人：見えない構造と多様な解釈
禅の達人：無心と悟りの実践
唯識思想の達人：心の構造を見抜く
法華経の達人：普遍的智慧と慈悲を実践
密教曼荼羅の達人：象徴と悟りの道
キリスト教神学の達人：信仰と理性の融合
ヒンドゥー哲学の達人：多様な道と統一の真理
ヨーガ哲学の達人：心身一如の道
神道思想の達人：自然と神々の調和
アフリカ哲学の達人：共同体と生命の智慧
ラテンアメリカ哲学の達人：解放とアイデンティティ
ネイティブアメリカン哲学の達人：大地と精霊の教え
ケルト神話思想の達人：物語と自然の調和
北欧神話思想の達人：運命と勇気の物語
ギリシャ神話思想の達人：英雄と神々の教訓
ルネサンス人文主義の達人：人間の価値と尊厳
啓蒙思想の達人：理性と進歩を信じる
浪漫主義思想の達人：感性と想像力を解き放つ
構造主義文学の達人：物語の構造を読み解く
ポストモダン思想の達人：多様性の相対性を受け入れる
サイエンス哲学の達人：科学の基盤を問い直す
数学哲学の達人：数の本質を探る
論理哲学の達人：推論と真理の構造を解く
環境哲学の達人：自然と人間の共生を考える
未来倫理学の達人：テクノロジーと人類の共進化
古代ローマの達人：帝国と法の源流
平家物語の達人：盛者必衰の理を知る
ユリウス・カエサルの達人：果断と戦略の達人
エリザベス一世の達人：知略と外交の女王
ルネサンスの達人：人間復興の精神
科学革命の達人：知のパラダイム転換
明治維新の達人：変革と先駆者
三国志の達人：智勇と人心掌握
徳川家康の達人：長期戦略の名手
豊臣秀吉の達人：機知と人材登用
織田信長の達人：革新と果断の覇者
聖徳太子の達人：和の政治家
江戸時代の達人：持続可能な繁栄
本居宣長の達人：日本文学の探究者
第一次世界大戦の達人：近代戦と国際秩序の変容
第二次世界大戦の達人：総力戦と復興の知恵
古代ギリシャの達人：民主と哲学の源流
アレクサンドロス大王の達人：遠征と帝国の築き方
古代エジプトの達人：永続と象徴の力
古代中国の達人：諸子百家の知恵
韓非子の達人：法治と権力の運用
孫子兵法の達人：戦わずして勝つ
ナポレオンの達人：迅速果断な行動力
クレオパトラの達人：魅力と政治術
産業革命の達人：技術と社会変革
アメリカ独立戦争の達人：自由と国家建設
南北戦争の達人：統一と変革の戦略
リンカーンの達人：不屈のリーダーシップ
ヴィクトリア女王の達人：安定と繁栄の時代
ガンジーの達人：非暴力と真理の力
ネルソン・マンデラの達人：和解と共生の精神
チャーチルの達人：言葉と行動の指導者
ケネディの達人：未来を語る政治力
冷戦期外交の達人：均衡と抑止の戦略
キューバ危機の達人：瀬戸際の交渉術
欧州統合の達人：多様性を束ねる政治
明治維新群像の達人：改革と近代化
坂本龍馬の達人：異文化をつなぐ交渉力
西郷隆盛の達人：信義と包容力
大久保利通の達人：制度設計と実行力
渋沢栄一の達人：道徳と経済の融合
近代日本外交の達人：国際感覚と交渉術
第一次大戦外交の達人：戦争と平和の狭間
第二次大戦外交の達人：同盟と復興の知恵
マーシャル・プランの達人：経済復興の戦略
国連創設の達人：多国間協調の設計者
宇宙開発競争の達人：先端技術と威信
現代中国の達人：成長と統制の戦略
現代インドの達人：多様性と成長の舵取り
アフリカ独立運動の達人：自己決定と国家建設
ラテンアメリカ革命の達人：社会改革と独立
中東和平交渉の達人：対立解消の外交術
EU拡大の達人：経済圏と政治連合の拡張
現代アメリカ政治の達人：分断と統合の課題
21世紀外交の達人：多極化時代の舵取り
パンデミック対応の達人：危機下の統治と協力
気候変動外交の達人：地球規模課題の解決
国際法発展の達人：秩序と正義のルール作り
情報戦略の達人：メディアと世論操作
サイバー戦争の達人：デジタル時代の安全保障
ケインズ経済学の達人：需要創出で経済を動かす
マルクス経済学の達人：資本主義の構造を読み解く
マネタリズム経済学の達人：通貨供給で経済を抑制する
シュンペーター経済学の達人：革新と企業家精神
構造経済学の達人：産業構造から成長戦略を描く
古典派経済学の達人：市場の自律性を信じる
重商主義の達人：国家主導で富を貯蓄
自由放任主義の達人：最小限の介入で成長
新古典派経済学の達人：効率と均衡の分析
制度派経済学の達人：制度と行動の関係を読む
行動経済学の達人：人間の非合理を活かす
期待効用理論の達人：不確実性下の選択
プロスペクト理論の達人：損失回避の心理
ゲーム理論応用の達人：駆け引きと協調の最適化
契約理論の達人：取引の枠組みを最適化
公共選択論の達人：政治と経済の接点を読む
厚生経済学の達人：社会全体の幸福を測る
環境経済学の達人：持続可能性を数値化
都市経済学の達人：都市の成長と課題を分析
農業経済学の達人：食糧と土地の最適利用
国際経済学の達人：貿易と投資の動態
国際金融論の達人：通貨と資本の流れを読む
開発経済学の達人：新興国の成長戦略
地域経済学の達人：ローカル資源の活用
マクロ経済モデルの達人：全体像から政策を描く
ミクロ経済分析の達人：個別行動から市場を読む
財政学の達人：税と支出で社会を動かす
金融工学の達人：リスクを数理で制御
ポートフォリオ理論の達人：最適投資配分
CAPM理論の達人：市場とリスクの価格
ブラック＝ショールズの達人：オプション価格の数理
市場効率仮説の達人：価格に全情報を織り込む
バブル経済研究の達人：熱狂と崩壊のメカニズム
景気循環論の達人：波を読んで動く
貨幣数量説の達人：通貨供給と物価の関係
現代貨幣理論の達人：財政赤字と成長の関係
信用創造の達人：銀行の力を活かす
為替理論の達人：通貨価値の変動を読む
貿易収支理論の達人：国際収支を最適化
産業組織論の達人：市場構造と戦争戦略
イノベーション経済学の達人：革新で成長を牽引
知識経済論の達人：情報を資本に変える
ネットワーク経済学の達人：つながりが価値を生む
シェアリング経済の達人：資産を共有し活用
デジタル経済の達人：情報技術で価値創造
AI経済学の達人：アルゴリズムと市場変容
行動金融学の達人：感情と市場の相互作用
実験経済学の達人：仮説を市場で検証
時系列分析の達人：データから未来を読む
計量経済学の達人：数理で経済を解明
資源経済学の達人：有限資源の最適利用
エネルギー経済学の達人：供給と需要の均衡
労働経済学の達人：人材市場の動態を分析
人工経済学の達人：人口変動と成長戦略
幸福の経済学の達人：主観的満足度を高める
医療経済学の達人：健康と財政の両立
教育経済学の達人：人材育成と成長の関係
犯罪経済学の達人：違法行動の経済分析
スポーツ経済学の達人：競技と市場の力学
文化経済学の達人：訪問者と地域の相互利益
不動産経済学の達人：土地と建物の最適活用
交通経済学の達人：移動と物流の効率化
海運経済学の達人：海上輸送の戦略
航空経済学の達人：空のネットワークと市場
宇宙経済学の達人：新たな市場の開拓
海洋資源経済の達人：持続可能な利用戦略
気候経済学の達人：温暖化対策と費用便益
災害経済学の達人：被害と復興の経済分析
ポーター戦略論の達人：競争優位の設計者
クリステンセンイノベーション理論の達人：破壊的革新の開拓者
リソース・ベースト・ビューの達人：資源を核に競争力を構築
学習する組織の達人：知の循環を生み出す
ブルーオーシャン理論の達人：競争のない市場を創造
バランス・スコアカードの達人：戦略を可視化し実行
ゲーム理論の達人：戦略的思考で勝つ
ダイナミック・ケイパビリティ理論の達人：環境変化に適応する力
エージェンシー理論の達人：情報の非対称性を制御する
取引費用理論（TCE）の達人：組織境界を最適化する
リアル・オプション理論の達人：不確実性を価値に変える
アッパーエシュロン理論の達人：トップの特性が戦略を決める
両利きの経営の達人：探索と深化を両立する
知識創造理論（SECIモデル）の達人：知を循環させる
リーダーシップ心理学の達人：人を動かす心の科学
モチベーション心理学の達人：やる気の源泉を引き出す
マインドフルネス心理学の達人：今この瞬間に集中する
センスメイキング理論の達人：意味づけで行動を導く
ソーシャルキャピタル理論の達人：信頼とネットワークが資本
進化・生態系アナロジーの達人：環境適応と共進化
レッドクイーン理論の達人：競争下での持続的進化
ドラッカー企業論の達人：企業の目的は顧客創造
ドラッカーマネジメント論の達人：成果を上げる管理者
ドラッカーイノベーション論の達人：体系的革新の実践者
ドラッカーポスト資本主義論の達人：知識社会の指針
ドラッカー知的労働者論の達人：知的生産性の最大化
ドラッカーリーダーシップ論の達人：使命と責任の遂行
ドラッカー利益の本質論の達人：利益は条件であって目的ではない
ドラッカー投資判断の達人：資源配分の最適化
ミンツバーグ組織論の達人：多様な組織形態を理解する
コトラーSTP理論の達人：市場を見極めて攻略する
サービス・ドミナント・ロジックの達人：価値共創の発想
トヨタ生産方式の達人：無駄を排し品質を高める
マズロー欲求理論の達人：人間の動機を理解する
TOCドラム・バッファー・ロープの達人：制約駆動の生産管理
TOCプロジェクトマネジメントの達人：クリティカルチェーンの使い手
熟達の達人：自己成長と内発的動機
メンタルモデルの達人：前提・思い込みを可視化し、検証・更新
共有ビジョンの達人：心から望む将来性を組織で共有
チーム学習の達人：対話（ダイアログ）で相互理解と洞察を深める
システム思考の達人：全体俯瞰の力
ニューロ意思決定理論の達人：脳科学で選択を最適化
ニューロ習慣形成理論の達人：脳の回路で行動を変える
ニューロアテンション理論の達人：集中力の神経科学
ソーシャルブレイン理論の達人：社会的つながりを脳から理解
デフォルトモードネットワーク理論の達人：内省と創造の脳回路
ニューロ・ストレス理論の達人：脳科学でストレスを制御
報酬予測誤差理論の達人：学習と動機を脳科学で解く
意思決定バイアス脳科学の達人：無意識の選択を解析
前頭前野活性化の達人：創造と計画の中枢
扁桃体制御の達人：感情反応を最適化
海馬記憶強化の達人：学習効率を高める
ミラーニューロン活用の達人：共感力を高める
脳可塑性促進の達人：変化に適応する神経回路
セロトニン調整の達人：安定した心を保つ
ドーパミン活性の達人：やる気と快楽を引き出す
オキシトシン促進の達人：信頼関係を深める
コルチゾール管理の達人：ストレス反応を整える
脳波トレーニングの達人：集中とリラックスを自在に
ビジュアライゼーション脳科学の達人：想像力で成果を引き出す
習慣回路形成の達人：望ましい行動を自動化
脳疲労回路の達人：認知機能をリセット
睡眠脳科学の達人：休息で能力を高める
マルチタスク制御の達人：脳負荷を最適化
瞑想脳科学の達人：意識と感情を調和
ニューロマーケティングの達人：脳反応から購買を促す
認知バイアス解除の達人：誤った思考を修正
自己効力感理論の達人：自身が行動を変える
心理的安全性理論の達人：安心して意見を言える場をつくる
フット・イン・ザ・ドア理論の達人：小さな承諾から大きな成果へ
ドア・イン・ザ・フェイス理論の達人：譲歩で合意を導く
ザイアンス効果：接触回数で好意を育む
アンカリング効果の達人：最初の情報が判断を左右する
フレーミング効果の達人：提示の仕方で選択を変える
自己決定理論の達人：内発的動機を引き出す
フロー理論の達人：没頭の力で成果を上げる
社会的証明理論の達人：他者の行動で影響を与える
一貫性の原理の達人：継続的行動を引き出す
希少性の原理の達人：価値を高め購買を促す
返報性の原理の達人：信頼関係を築く
ピークエンド効果の達人：印象に残る体験を設計
損失回避の達人：行動を促す心理設計
タイムディスカウントの達人：未来価値を意識させる
ナッジ理論の達人：行動変容をさりげなく誘導
もの言う株主：いうべきことをいう投資家
もの言う顧客：いうべきことをいう顧客
もの言う社員：いうべきことをいう従業員
もの言うアクティビスト：株主還元圧力の強い投資家
スーパーCEO：経営・ビジョン・意思決定のプロ
スーパーCFO：財務・資金計画・利益・コストのプロ
スーパーCTO：技術・研究・開発・イノベーションのプロ
スーパーCMO：営業・マーケティング・ブランティングのプロ
スーパーCSO：協業・アライアンス・M&Aのプロ
スーパーCDIO：DX・IT・AIによる企業変革のプロ
スーパーCHRO：人財・組織・採用・教育のプロ
スーパーCLO：法務・契約・株主対応のプロ
スーパーCRO：リスク・レピュテーション対応のプロ
Dr.経営思想：世界を変えた経営思想と実践
Dr.競争思想：競争戦略を生かす達人
Dr.革新発想：新発想を生む達人
Dr.歴史思想：歴史や古典の発想を実践する達人
Dr.コンセプト：コンセプトとストーリーづくりの達人
Dr.進化思想：内発的生成発展から考える達人
未来洞察の達人：長期視点で戦略を描く
逆転発想の達人：常識を覆す新視点
異分野融合の達人：知識を掛け合わせる
メタ認知力の達人：自分の思考を客観視
シナリオプランニングの達人：複数未来を準備
意思決定加速の達人：素早く最適解に到達
問題定義の達人：核心を見抜く
ストーリーテリングの達人：心を動かす語り
可視化の達人：情報を直観的に理解させる
制約活用の達人：限界から創造する
AI戦略の達人：人工知能で価値創造
機械学習応用の達人：データから未来を導く
ディープラーニングの達人：複雑課題を解く脳
自然言語処理の達人：言葉を理解し価値化
生成AI活用の達人：創造と効率を両立
AI理論の達人：公平性と透明性を守る
ロボティクスの達人：自動化で未来を開く
自律移動システムの達人：移動の自由を革新
人間拡張技術の達人：身体能力を進化させる
AR/VR戦略の達人：没入体験で市場を変える
メタバース経営の達人：仮想空間で価値創造
量子コンピューティングの達人：計算革命を起こす
ポスト量子暗号の達人：量子コンピュータ時代の暗号技術
暗号技術の達人：暗号技術の理論と応用
ブロックチェーンの達人：分散型信頼を構築
スマートコントラクトの達人：自動契約で効率化
Web3戦略の達人：分散型インターネットを活かす
IoT活用の達人：つながる世界で効率化
エッジコンピューティングの達人：リアルタイム処理強化
クラウド戦略の達人：柔軟で拡張可能な基盤
ハイブリッドクラウドの達人：最適環境を組み合わせる
サイバーセキュリティの達人：防御と復旧を徹底
ゼロトラストの達人：信頼しない設計思想
データガバナンスの達人：情報資産を守り活かす
データサイエンスの達人：分析で意思決定を支える
ビッグデータ活用の達人：大量情報から価値を抽出
予測分析の達人：未来を数理で読む
データ可視化の達人：情報を直観的に伝える
AI創薬の達人：医療革新を加速
バイオインフォマティクスの達人：生命情報を解析
合成生物学の達人：生命を設計する
遺伝子編集の達人：生命コードを改変
再生医療の達人：失われた機能を回復
ニューロテクノロジーの達人：脳と機械をつなぐ
感情認識AIの達人：心を読み取る技術
ヒューマン・マシン協働の達人：共創型作業を実現
スマートシティ戦略の達人：都市の未来を設計
クリーンエネルギー技術の達人：持続可能な電力供給
水素エネルギー活用の達人：次世代燃料を推進
カーボンキャプチャの達人：CO2を資源化
宇宙開発戦略の達人：地球外市場を開拓
小型衛星ビジネスの達人：宇宙データを活かす
宇宙旅行事業の達人：地球を超える体験提供
軌道サービスの達人：宇宙インフラを維持
深海探索技術の達人：未知の資源を開発
未来交通システムの達人：移動の概念を刷新
ナノテクノロジーの達人：物質を原始レベルで制御
スマートマテリアルの達人：環境適応型素材を創る
ルネサンス美術の達人：芸術と科学の融合
印象派絵画の達人：瞬間の光を捉える
抽象芸術の達人：形なき世界を描く
浮世絵の達人：日常を美に昇華する
書道の達人：一筆に心を宿す
陶芸の達人：土と火で形を生む
建設デザインの達人：空間で感動を設計
都市景観デザインの達人：街並みを芸術に変える
映画制作の達人：映像で物語を紡ぐ
脚本創作の達人：言葉で世界を構築
舞台演出の達人：空間と時間を操る
現代音楽の達人：音で感性を揺さぶる
クラシック暗号の達人：調和と構造の美
ジャズ即興の達人：自由な対話で創造
民族音楽の達人：伝統と現代をつなぐ
写真芸術の達人：瞬間を永遠に残す
映像編集の達人：視覚の流れをデザイン
グラフィックデザインの達人：視覚で伝える力
タイポグラフィの達人：文字に命を吹き込む
プロダクトデザインの達人：使いやすさと美の融合
ファッションデザインの達人：装いで個性を表現
テキスタイルアートの達人：布で物語を紡ぐ
宝飾デザインの達人：輝きで魅力を引き出す
香りのデザインの達人：嗅覚で記憶を呼び起こす
食のアートの達人：味覚と美を融合
ガストロノミーの達人：食文化を革新
茶道の達人：一服に心を込める
華道の達人：花で空間を彩る
庭園設計の達人：自然と人工の調和
民芸の達人：日用品に美を宿す
ストリートアートの達人：街に新しい息吹を吹き込む
コミックアートの達人：絵と言葉で物語る
ゲームデザインの達人：遊びで没入体験を創出
UI/UXデザインの達人：心地よい体験を設計
インスタレーションアートの達人：空間と感覚を融合
パフォーマンスアートの達人：瞬間芸術で心を動かす
朗読の達人：声を物語を紡ぐ
即興演劇の達人：瞬間の創造力を引き出す
創作ダンスの達人：身体で物語を描く
伝統芸能の達人：古き技を現代に活かす
民話語りの達人：口承で文化を継ぐ
アートセラピーの達人：創作で心を癒す
色彩心理の達人：色で感情を操る
音響デザインの達人：音で空間を演出
映像美学の達人：光と構図を魅せる
クリエイティブライティングの達人：文章で感情を動かす
詩作の達人：言葉で世界を凝縮する
企業倫理の達人：信頼と持続性を守る
コンプライアンス経営の達人：規範を力に変える
CSR戦略の達人：社会責任を経営資源化
企業統治の達人：透明性と説明責任を確保
取締役会運営の達人：意思決定の質を高める
内部統制の達人：組織の健全性と維持
情報公開の達人：透明な組織を築く
デジタル倫理の達人：技術と価値観の調和
プライバシー保護の達人：個人情報を守る
知的財産戦略の達人：創造を守り育てる
特許活用の達人：独自技術で市場を制す
契約交渉の達人：有利な条件を引き出す
国際法の達人：越境ビジネスの指針
貿易実務の達人：国境を超える取引を円滑化
人権尊重の達人：すべての人に尊厳を
労働法遵守の達人：働きやすい環境を守る
環境法規対応の達人：地球を守る経営
反腐敗対策の達人：公正な市場を守る
危機管理法務の達人：法的リスクに即応
内部告発制度の達人：正義を守る仕組み
取引先監査の達人：サプライチェーンの透明性
国際認証の達人：基準適合で信頼を獲得
AIガバナンスの達人：アルゴリズムを統制
データ主権の達人：国境を越える情報を管理
倫理的リーダーシップの達人：規範で導く
持続可能なガバナンスの達人：未来志向で組織を導く
多国籍企業法務の達人：国境を超えた規制対応
海洋法の達人：海の資源と安全を守る
宇宙法の達人：地球外活動のルール
遺伝子倫理の達人：生命改変の境界を守る
バイオセーフティの達人：生命科学の安全管理
メディア倫理の達人：情報の公正を守る
広告規制の達人：誤解なき情報提供
金融規制対応の達人：健全な市場運営
保健法務の達人：安心を支える契約設計
税務コンプライアンスの達人：適正申告を徹底
相続・事業継承法務の達人：円滑な引き継ぎを実現
地域条例対応の達人：地域密着で規制遵守
国際紛争解決の達人：平和的交渉と合意形成
企業倫理研修の達人：全員で価値観を共有
危機広報法務の達人：リスクを事前に排除
国際コンプライアンスの達人：世界基準で運営
未来型法務の達人：新領域のルール設計
物理学の達人：自然法則で戦略を読む
力学応用の達人：バランスと推進力を最適化
熱力学の達人：エネルギー効率を極める
量子物理の達人：不確実性を活かす
相対性理論の達人：視点を変えて真理を捉える
光学の達人：情報と可視化を操る
音響科学の達人：音の力で環境を変える
化学反応設計の達人：組み合わせで新価値創造
有機化学の達人：生命に近い素材を開発
無機化学の達人：産業を支える素材革命
材料科学の達人：特性を操り新素材を創る
ナノ材料の達人：原子レベルの機能設計
電気工学の達人：エネルギーと通信を制御
再生可能エネルギーの達人：持続可能な電力供給
太陽光発電の達人：光から無限の力を得る
風力発電の達人：風の力を経済に変える
地熱エネルギーの達人：地球の熱を活用
潮力発電の達人：海の力を電力に変える
水資源管理の達人：持続可能な利用を設計
森林保全の達人：生態系サービスを守る
海洋保全の達人：豊かな海を未来へ継ぐ
生物多様性保護の達人：生命のネットワークを維持
都市環境デザインの達人：自然と共生する街づくり
循環経済の達人：廃棄物を資源に変える
廃棄物管理の達人：減量と再利用を促進
気候変動科学の達人：データで未来を予測
温暖化対策の達人：排出削減を加速
環境政策設計の達人：持続性を制度化
環境教育の達人：意識変革を促す
都市気候対策の達人：ヒートアイランドを防ぐ
災害リスク科学の達人：予測と備えを強化
地震工学の達人：揺れに強い構造を設計
火山学の達人：噴火リスクを理解する
気象予測の達人：天候を先読み
氷河学の達人：氷の変化から地球を読む
海洋学の達人：海の流れと資源を理解
陸水学の達人：淡水資源の管理と保全
生態系サービスの達人：自然の恵みを経営に活かす
土壌科学の達人：大地の健康を守る
植物学の達人：緑の知恵をくらしに活かす
動物行動学の達人：生命の戦略を学ぶ
昆虫学の達人：小さな生命から学ぶ
微生物学の達人：見えない生命を活用
環境工学の達人：技術で自然を守る
グリーンインフラの達人：自然を活かす社会基盤
サステナブルデザインの達人：持続可能性を形にする
予防医学の達人：健康寿命を延ばす戦略
公衆衛生の達人：社会全体の健康を守る
感染症対策の達人：拡大を防ぐ仕組みづくり
栄養学の達人：食事で心身を整える
スポーツ栄養学の達人：競技力と回復力を高める
運動生理学の達人：体の仕組みを動かす
筋力トレーニング科学の達人：強さを科学で伸ばす
持久力向上の達人：長く戦う力を養う
柔軟性強化の達人：しなやかな体を育てる
バイオメカニクスの達人：動作効率を最適化
リハビリテーションの達人：機能回復を支える
作業療法の達人：日常動作を再設計
理学療法の達人：身体機能を科学的に改善
脳神経リハビリの達人：神経可塑性を活かす
姿勢改善の達人：体の軸を整える
呼吸法の達人：酸素効率を最大化
マインドフルネス健康法の達人：心身を調和
ストレス管理の達人：心の負荷を最小化
睡眠科学の達人：回復と成長を促す
体組成管理の達人：理想のバランスを維持
減量戦略の達人：安全かつ持続可能に痩せる
加齢科学の達人：老化を遅らせる
ホルモンバランス調整の達人：内分泌を味方に
免疫強化の達人：病気に負けない体づくり
有酸素運動の達人：心肺機能を高める
無酸素運動の達人：瞬発力と筋力を磨く
コーチング科学の達人：才能を引き出す指導法
スポーツ心理学の達人：心の強さを育てる
チームスポーツ戦略の達人：集団で勝つ方法
モーターコントロールの達人：動きを正確に操る
反応速度強化の達人：瞬時の判断力を養う
平衡感覚向上の達人：安定と敏捷性を高める
リカバリー戦略の達人：疲労回復を最適化
温熱療法の達人：体温で回復を促す
冷却療法の達人：炎症と疲労を抑える
水中運動の達人：負荷と負担のバランス
高地トレーニングの達人：酸素不足で体を鍛える
呼吸筋トレーニングの達人：呼吸力を強化
姿勢制御の達人：体の安定性を高める
フィットネスプログラム設計の達人：目標別に最適化
競技分析の達人：データで勝利を設計
健康経営の達人：社員の活力を最大化
ウェルビーイング科学の達人：幸福度を測り高める
セルフケア戦略の達人：自分を守る習慣を作る
緊急医療の達人：緊急時の最善判断

以上です。

2025年振り返り

Sat, 27 Dec 2025 00:00:00 +0000

2025年に対する個人的な駄文です。

仕事面

IR情報ですでに公開されている内容ですが、弊社の主力製品の次期プロダクト開発が始まっています。一番に掲げる目標は「クラウド最適化」によるコスト削減となっており、そこに向けてプロジェクトを進めている真っ最中です。私自身は設計・開発メンバーおよび基盤領域のサブリーダーとして参加していて、古い技術と新しい技術の両方を把握した上で、品質に影響の出ないようにどのように作り変えていくのか、安定した新しい基盤を提供するにはどうすれば良いか、という課題と日々向き合っています。ときには方向性の違いで議論に熱が入ってしまうこともありますが、今までの経験を活かして良い意味で現行システムを否定し、新しいシステムに活かすことができるので、楽しく仕事ができております。

自部署の次年度予算策定のための計画作成にも関わり、現実的で実現可能な計画ができたと思っています。この資料をもとに会社の方向性を勘案しながら人員計画が作られていくのを見ていると、会社の意思決定はこういうふうに決まっていくのかー、という感じで学びのある機会でした。プロジェクトは来年も続くので、引き続き頑張っていきたいと思います。

プライベート面

今年は技術評論社の技術誌『Software Design』にて、2025年3月号〜12月号にかけて連載「乱数のひみつ」、同11月号にて特別企画「量子コンピュータを支えるしくみ」、来年の1月号から新連載「暗号のひみつ」を執筆しました。合計で11本の原稿を提出し、編集さんと協力して校正作業などをしていました。どの連載・企画もすべて「現代暗号技術」という一点で共通した一貫性を維持するように執筆を心がけていました。私たちのデジタルな世界を支える暗号技術という基盤技術の面白さや奥深さについて、連載を通して読者の皆さんに共有できたらいいなと思っています。毎月原稿の締め切りを意識しながら執筆していて、さらにネタ探しも同時並行で行っていたので、暗号技術のことを考えなかった日はなかったです。数年前、仕事が忙しくて暗号技術から離れていた時期もあったのですが、今またこうして好きな暗号技術のことを考えられる日々を過ごせることを心から感謝しています。

仕事の方も基盤関係で、プライベートでの連載の方も基盤技術ですが、プライベートの方がより暗号や通信に特化した深い技術領域を扱っています。連載の方でもRFCの仕様について度々触れることがありますが、RFC翻訳対訳サイト（RFC Trans）の管理は5年以上続けていて、今も更新し続けています。少し前はAI（ChatGPT）にRFCを要約させていましたが、最近はAI（GoogleのGemini）に一部のよく参照されるRFCの翻訳内容をレビューさせ、校正を行っています。使った体感はかなり良い精度が出ています。特に暗号技術の専門用語などが正しく再翻訳されていく様子は圧巻です。 Geminiのコンテキストウィンドウ（100万トークン）はChatGPTよりも非常に長いため、RFCのような長い文書で全文読み込めるときにおすすめです。このような理由から、自分はGeminiに勝算があると判断し、Google AI Proに課金しています。

実は連載の原稿についても、執筆し終わったら必ずAI（Gemini）のレビューを受けるようにしています。暗号技術の観点から技術的な正確性に関するレビューと、教育心理学の観点から学習者への対人支援として適切な説明の流れになっているかのレビュー、校正の観点から図表やコードが本文と乖離していないかのレビュー、といった感じで複数のAIレビュワーを使いこなしています。

教育心理学や発達心理学は、過去にセキュリティキャンプでチューターや講師をしていたころから勉強していた内容で、私の教育に対する第一指針です。私の解釈ではアドラー心理学における教育とは「成績の良い子を育てることではなく、本人が自立できるように支援すること」が本質であると信じているので、いつでも立ち返るべき重要な視点として、専用のAIレビュワーを作成しています。自分の教育コンテンツの理想としては、現代社会に対して疑念を持ち（導入）、自分の頭で考えるきっかけ（展開）になるようなものが作れればいいなと常々思っております。

画像のレビューに関して、Geminiは画像解析も得意みたいで、連載で使用する画像をレビューさせたら、一発で問題点を指摘したこともあり、一目置いている存在です。ただ、そんな最強AIでも、原稿を0から作るのは難しく、試しに自由に書かせてみたら、面白くない話から連想ゲームをした結果みたいな原稿ができて、うーん（使い物にならない）となったことがあります。なので原稿作成については、自分で書きたい原稿の流れを決めて、ある程度自分で調査した結果を整理し、その上で調査結果Aと調査結果Bの説明がつながるように前後を補足してほしい、みたいな穴埋め問題的な場面に限定してAIを使っている、といった感じです。このおかげで編集さんによる校正で前後をつなげるための追加の説明が挿入される回数が減りました。

原稿の流れ決めや作図はほとんど自分の考えで作業しているので、今日までの私のAIに対する評価は、AIはレビューが非常に得意という程度です。仕事（本業）でもAIを使った生産性改善みたいな話は以前から上がっているので、ゆくゆくは仕事でも活用できればと思っています。

おわりに

最後になりますが、今の私がこうして技術的な活動ができるのは、周りの人の支えによるところです。仕事とプライベートのどちらの面においても、私の話を聞いてくれた人、お話してくれた人、相談に乗ってくれた人に感謝しております。来年も引き続き、心と身体に気を付けながら努力を積み重ねていきたいと思います。

[Python] LarkでMS-DOSコマンドの構文解析

Sat, 22 Nov 2025 00:00:00 +0000

一見単純に見えるMS-DOSのバッチファイル（CMDスクリプト）ですが、その裏側にはリダイレクト、変数展開、特殊文字のエスケープといった複雑なルールが隠されています。このような独自の文法を持つテキストをプログラムで正確に扱うには、構文解析が不可欠です。この記事では、Pythonの強力なパーサーライブラリ Lark を使い、MS-DOSコマンドの構文解析器（パーサー）をゼロから構築した方法を概要を説明します。

文法定義ファイル grammar.lark の書き方から、if や for といった制御構文、set や echo などの基本コマンド、さらには解析の難所である引数やリダイレクトの扱いまで、具体的なコード例と生成される構文木（AST）を交えながら説明していきます。

CMDファイルの「文法」を定義するために使用できるのが Python ライブラリの一つである Lark です。なお、今回作成したCMDファイルの構文解析プログラムは以下で公開しております。

tex2e/msdos-cmd-parser: MS-DOS Command Parser

上記で公開したレポジトリについて、このトランスパイラの心臓部となるのが、grammar.lark ファイルです。このファイルは、解析対象であるMS-DOSコマンド（CMD）の構文ルールをEBNF (Extended Backus-Naur Form) という形式で厳密に定義した「文法定義ファイル」です。

Pythonの強力なパーサーライブラリである Lark は、この文法定義ファイルを設計図として読み込み、CMDスクリプトを解析するためのパーサーを動的に生成します。

1. Larkと文法定義

Larkは、文法定義に従ってテキストを解析し、その構造をプログラムで扱いやすいAST (Abstract Syntax Tree / 抽象構文木) というデータ構造に変換してくれるツールです。

例えば、SET A=1 という単純なテキストも、人間にとっては「変数Aに1を代入するコマンド」と理解できますが、プログラムにとってはただの文字列です。文法定義ファイルには、以下のようなルールが記述されています。

コマンドは SET というキーワードで始まる場合がある。
SET の後には、空白を挟んで「変数名」が来る。
「変数名」の後には = が来る。
= の後には「値」が来る。

Larkは grammar.lark に書かれたこれらのルールに従うことで、SET A=1 という文字列を「SETコマンド」というノードに変換し、そのノードが「変数名=A」と「値=1」という子ノードを持つ、というような階層的な木構造（AST）を構築します。

後続の処理では、このASTを操作することで、元のCMDスクリプトの構造を理解できるため、C#のコードなどに変換できるようになります。

2. Larkの書き方

文法は主に2種類の要素で構成されます。

ルール (Rule)：文法の構成要素
ターミナル (Terminal): これ以上分解できない文法の最小単位（トークン）

ルールは、他のルールやターミナルを組み合わせて定義します。Larkでは通常、小文字で命名されます。（例: program, line, statement_if）ターミナルは、具体的な文字列や正規表現で定義します。Larkでは慣例的に大文字で命名されます。（例: IF, SET, FILEPATH）

基本的なEBNF記法

grammar.lark を読む上で重要な記号は以下の通りです。

記号	意味	例
`:`	ルールやターミナルを定義する	`program: ...`
`\\|`	「または (OR)」	`A \\| B` (AまたはB)
`?`	直前の要素が省略可能 (0回または1回)	`NL?` (改行はあってもなくても良い)
`*`	直前の要素が0回以上繰り返し	`A*` (Aが0回以上繰り返す)
`+`	直前の要素が1回以上繰り返し	`A+` (Aが1回以上繰り返す)
`()`	グループ化	`(A B)+` (AとBの並びが1回以上繰り返す)
`i`	`"`の後の `i` は大文字小文字を区別しない	`SET: "set"i`
`/ /`	正規表現によるターミナル定義	`VARIABLE_NAME: /[^=]+/`
`->`	ルールに別名（エイリアス）を付ける	`... -> test_not_exist` (Transformerで扱いやすくなる)
`.N`	ルールの優先度を指定 (数字が大きいほど高い)	`command_rem.9: ...` (文法の曖昧さを解決するために使用)

具体的なルールの例

Larkの構文ルールの書き方に関して、いくつか具体的なルールの例を紹介します。

エントリーポイント

Lark は必ず「start」ルールから始まります。

// 構文解析のエントリーポイント
?start: program

// プログラムは複数のコメント行か命令行
program: WS? (command_rem NL WS_INLINE? | line WS_INLINE? NL WS_INLINE? | emptyline)+

?start: 解析の開始地点。?を付けると、生成されるAST上でこのノードが省略（インライン化）されます。
program: スクリプト全体を表すルール。line（命令行）やcommand_rem（コメント行）などが1回以上繰り返される(+)ことで構成されると定義しています。

IF文

statement_if.5: IF WS_INLINE test WS_INLINE line (WS_INLINE? statement_else)?

statement_else.5: ELSE WS_INLINE statement_if
                | ELSE WS_INLINE line

IF: "if"i
ELSE: "else"i

statement_if ルールは、IF ターミナル、test ルール（条件式）、そして実行される line ルール（コマンド）から構成されることを示します。
| を使って、else句 (statement_else) が続くパターンも定義されています。? によりelse句は省略可能です。

複雑な引数を捉える正規表現

// コマンドの引数。リダイレクト（>&|）と改行（\n）と丸括弧閉じ（)）以外の全てにマッチする
ARG_VALUE_IN_PAREN.2: /
    (    \^.                                             # キャレットによるエスケープ
        |"(^"|[^"]++)*+"                                 # 文字列の囲み
        |(?<paren>\((^\)|[^()\r\n]++|(?&paren))*+\))     # 丸括弧の囲み
        |[^^\r\n<>()&|^"12]++                            # 値
    )+
/x

CMDのコマンド引数は、変数展開 (%VAR%)、引用符、特殊文字のエスケープなどが絡み合い、非常に複雑です。このような複雑な文字列パターンを正確に捉えるために、ターミナル定義では正規表現が多用されます。 /x フラグは、正規表現内にコメントや空白を入れることを許可し、可読性を向上させるためのものです。

3. Larkの便利な機能

Larkには以下の2つの組み込みの命令が存在します。

%import
%ignore

%import は grammar.lark の末尾で common.DIGIT や common.LETTER をインポートするときに使われています。これはLarkに標準で組み込まれている共通のターミナル定義を再利用するための機能です。

また、%ignore は指定したターミナルを解析時に無視するよう指示します。ただし、MS-DOSの文法においてはECHOなどで、空白の有無が重要な意味を持つケースが多いため、グローバルな %ignore は使わず、WS_INLINE のような空白ルールを文法内に明示的に記述する戦略を取っています。

このように grammar.lark は、トランスパイラの挙動を支えるための、緻密かつ可読性の高い設計図として機能しています。この文法定義があるからこそ、LarkはCMDスクリプトの構造を正確に解析し、後続の処理で扱いやすいASTへと変換することができるのです。

4. `grammar.lark` 詳細解説

grammar.lark の文法定義は、「構造」「制御フロー」「コマンド」「引数」といった主要な要素から構成されています。このセクションでは、具体的なCMDコマンドの例を交えながら、文法の中心となるルールの役割を解説していきます。

4.1 スクリプトの基本構造

まず、スクリプト全体の骨格を定義するルールについて説明します。

`program`

?start: program
program: WS? (command_rem NL ... | line NL ... | emptyline)+

program ルールは、CMDスクリプト全体の構造を定義する中心的な役割を担います。スクリプトは、rem で始まるコメント行 (command_rem)、後述するコマンドやステートメントなどの実行可能な行 (line)、そして空行 (emptyline) の3種類の行が1つ以上繰り返されることで構成されます。

例えば、以下のような環境変数をセットしてgotoするだけのMS-DOSコマンドファイルを構文解析するとします。

@echo off
rem 初期設定
set VAR=100

goto :main

上記の内容を構文解析すると、以下の構文解析木が出力されます。なお、読みやすさ優先で出力結果を一部を手で修正しています。

program
  command_echo
    echo
  command_rem
    rem
  command_set
    set VAR=100
  emptyline
  command_goto
    goto

構文ルールでは初めに ?start: program と書きましたが、解析結果は「start」から始まらずに「program」から木が構築されています。これは、? をつけた場合、その要素（start）の子供が1個の要素（program）しか存在しないときに、親の要素が構文木上から省略されるためです。

続いて、「program」の要素の中には、複数の要素（command_* や emptyline など）が含まれています。構文ルール上では複数のパターンをOR演算子 | で連結し、さらにそれらが連続で出現できることを意味する繰り返し記号 + で表現されているためです。

`line` と `label`

?line: command_line | statement | label
label: COLON LABEL PLUS?

line ルールは、個々の行が「コマンド (command_line)」「ステートメント (statement)」「ラベル (label)」のいずれかであることを示します。 label は、コロン (:) で始まり、goto や call 命令の飛び先となる目印として機能します。

例えば、以下のようなechoで出力した後にif文で条件分岐するだけのMS-DOSコマンドファイルを構文解析するとします。

:main
echo Main process
if "%VAR%"=="100" (
    goto :end
)

:end
echo End

上記の内容を構文解析すると、以下の構文解析木が出力されます。なお、読みやすさ優先で出力結果を一部を手で修正しています。

program
  label :main
  command_echo
    echo Main process
  statement_if
    if
    test_comp
      "%VAR%" == "100"
    group
      (
      subprogram
        command_goto
          goto :end
      )
  emptyline	
  label
    :end
  command_echo
    echo End

4.2 制御フロー

次に、コマンドの実行順序を制御するためのルールを見ていきます。

`command_line` (コマンド連結)

?command_line: pipeline (CHAIN_OP WS_INLINE pipeline)*
CHAIN_OP: "&&" | "||" | "&"

command_line ルールは、&&（AND）、||（OR）、&（連続実行）といった演算子を用いて、複数のコマンドを1行に連結する構文を定義します。 && は左のコマンドが成功した場合に右を実行し、|| は失敗した場合に実行する演算子です。また、& は単純に左のコマンドに続けて右を実行するための演算子です。後述する pipeline は複数のコマンドをパイプラインで結合するための構文ルールですが、パイプラインがなければ1つのコマンドとなります。

例えば、以下のようなdirでCドライブの内容をファイルに保存成功したらechoするだけのMS-DOSコマンドファイルを構文解析するとします。

dir C:\ > output.txt && echo "dir command was successful."

上記の内容を構文解析すると、以下の構文解析木が出力されます。なお、読みやすさ優先で出力結果を一部を手で修正しています。

program
  command_line
    command_oneline
      command_exe
        dir C:\ 
      redirect_stdout
        > output.txt
    &&
    command_echo
      echo "dir command was successful."

`pipeline` (パイプライン)

?pipeline: command (PIPE WS_INLINE? command)*
PIPE: "|"

パイプライン処理は pipeline ルールによって定義されます。これは、| 記号を使い、あるコマンドの標準出力を別のコマンドの標準入力へと渡すための構文です。

例えば、以下のようなdirの出力結果から条件に一致する行を検索するMS-DOSコマンドファイルを構文解析するとします。

dir | find "bytes"

上記の内容を構文解析すると、以下の構文解析木が出力されます。

program
  pipeline
    command_exe
      dir
    |
    command_exe
      find
      "bytes"

`group` (コマンドのグループ化)

?command: command_oneline
        | PAREN_LEFT subprogram PAREN_RIGHT ... -> group

コマンドの構文ルールについて、丸括弧 () で囲まれていないときは、単一のコマンド command_oneline として解析します。一方で、丸括弧 () で囲まれているときは別名の group ルールとして解析します。 group ルールは、丸括弧 () を用いて複数のコマンドを一つのブロックとしてまとめる構文を定義します。この機能は、主に if 文や for 文の内部で、複数の処理を条件に応じて実行する場合などに必要です。括弧内のコードは subprogram という、グループ内で完結するサブスクリプトとして解析されます。

例えば、以下のようなif文のMS-DOSコマンドファイルを構文解析するとします。

if exist file.txt (
    echo file.txt exists.
    del file.txt
)

上記の内容を構文解析すると、以下の構文解析木が出力されます。なお、読みやすさ優先で出力結果を一部を手で修正しています。

program
  statement_if
    if
    test_exist
      exist file.txt
    group
      (
      subprogram
        command_echo
          echo file.txt exists.
        command_exe
          del file.txt
      )

4.3 ステートメント

if や for のような、より複雑なロジックを担う構文はステートメントとして定義されます。

`statement_if`

statement_if: IF WS_INLINE test WS_INLINE line (WS_INLINE? statement_else?)
test: ...

statement_if は、条件分岐を実現する if 文を定義します。このルールでは、else 句が省略可能であることも示されています。 if文の核心は test ルールにあります。ここでは if "%A%"=="B" のような文字列比較 (test_comp)、if exist file.txt のようなファイル存在確認 (test_exist)、if defined MY_VAR のような変数定義確認 (test_defined)、そして if errorlevel 1 のような終了コード判定 (test_errorlevel) といった、多彩な条件式が定義されています。

例えば、以下のようなif-else文で書かれたMS-DOSコマンドファイルを構文解析するとします。

if /i "%ANSWER%" equ "YES" (
    echo OK
) else (
    echo NG
)

上記の内容を構文解析すると、以下の構文解析木が出力されます。なお、読みやすさ優先で出力結果を一部を手で修正しています。

program
  statement_if
    if
    test_comp
      /i "%ANSWER%" equ "YES"
    group
      (
      subprogram
        command_echo
          echo OK
      )
    statement_else
      else
      group
        (
        subprogram
          command_echo
            echo NG
        )

`statement_for`

statement_for_f: FOR "/f" for_parameter IN PAREN_LEFT for_range PAREN_RIGHT DO line
statement_for_l: FOR "/l" for_parameter IN PAREN_LEFT for_range_start_step_end PAREN_RIGHT DO line
statement_for_r: FOR "/r" ...

ループ処理は statement_for によって定義されます。 CMDの for コマンドは非常に多機能であるため、文法定義もオプションごとに細分化されています。例えば、/f オプションはファイル内容やコマンド結果を行単位で処理するための statement_for_f、/l オプションは数値範囲でループするための statement_for_l、/r オプションはディレクトリを再帰的に探索するための statement_for_r といったルールがそれぞれ用意されています。

例えば、以下のようなfor文で書かれたMS-DOSコマンドファイルを構文解析するとします。

rem "test.txt"の各行を処理
for /f "delims=" %%a in (test.txt) do echo LINE: %%a

上記の内容を構文解析すると、以下の構文解析木が出力されます。なお、読みやすさ優先で出力結果を一部を手で修正しています。

program
  command_rem
    rem "test.txt"の各行を処理
  statement_for_f
    for
    /f
    "delims="
    for_parameter
      %%a
    in
    (
    for_range_filename	test.txt
    )
    do
    command_echo
      echo LINE: %%a

4.4 基本コマンド

set や echo のように頻繁に使用される基本的なコマンド群も、それぞれ専用のルールを持っています。

`command_set`

command_set: SET ... VARIABLE_NAME ... EQ ARG_VALUE_IN_SET?

command_set ルールは、set コマンドによる環境変数の代入操作を定義します。この定義には、/a オプションによる数値計算や /p オプションによるユーザー入力の受付といった派生的な使い方も含まれています。

以下はサンプルのMS-DOSコマンドファイルとその解析結果の構文木の内容です。

set MyVar=Hello World
set /a Counter=1+1

program
  command_set
    set
    MyVar
    =
    Hello World
  command_set_expr
    set
    /a
    Counter
    =
    1+1

`command_echo`

command_echo: ECHO ... ARG_VALUE_IN_PAREN? | ECHODOT ...

command_echo は、echo コマンドによる文字列表示を定義するルールです。また、改行のみを出力する echo. という特殊なケースも ECHODOT という専用のルールで明確に区別して扱います。

以下はサンプルのMS-DOSコマンドファイルとその解析結果の構文木の内容です。

echo Hello
echo.

program
  command_echo
    echo
    Hello
  command_echo	echo.

`command_call` / `command_goto`

call と goto は、スクリプトの実行フローを制御する重要なコマンドです。 call は別のバッチファイルや、コロンで定義されたサブルーチン（ラベル）を呼び出すために使われます。一方、goto は指定されたラベルへ無条件に実行をジャンプさせます。

以下はサンプルのMS-DOSコマンドファイルとその解析結果の構文木の内容です。

call :subroutine
goto :end

program
  command_call_label
    call
    label
      :subroutine
  command_goto
    goto
    :end

`command_exe`

command_exe: FILEPATH WS_INLINE ARG_VALUE_IN_PAREN?

これまでに挙げたどの専用ルールにも一致しないコマンドは、この汎用的な command_exe ルールによって「外部コマンド実行」として解釈されます。 copy, del, xcopy といった標準コマンドや、ユーザーが作成した独自の実行ファイルなどがこれに該当します。

copy "C:\source\data.txt" "D:\backup\"
MyApplication.exe /param1 /param2

以下はサンプルのMS-DOSコマンドファイルとその解析結果の構文木の内容です。

program
  command_exe
    copy
    "C:\source\data.txt" "D:\backup\"
  command_exe
    MyApplication.exe
    /param1 /param2

4.5 リダイレクト

?redirect: redirect_stdout | redirect_stderr
redirect_stdout: IO1_REDIRECT ... REDIRECT_TARGET

redirect ルールは、コマンドの出力をファイルなどへ切り替えるリダイレクト構文を定義します。これには、標準出力を上書きまたは追記する > や >>、そして標準エラー出力を扱う 2> などが含まれます。

rem 標準出力をlog.txtに上書き
dir > log.txt

rem 標準エラー出力をerror.logに追記
some_command 2>> error.log

program
  command_rem
    rem
    標準出力をlog.txtに上書き
  command_oneline
    command_exe
      dir
    redirect_stdout
      >
      log.txt
  emptyline	
  command_rem
    rem
    標準エラー出力をerror.logに追記
  command_oneline
    command_exe
      some_command
    redirect_stderr
      2>>
      error.log

4.6 最も複雑なルール：引数と値

CMD構文の解析において最大の難関となるのが、コマンドの引数部分です。なぜなら、引数の中にはリダイレクト演算子 (>, <) やコマンド連結演算子 (&) といった、文法上特別な意味を持つ文字が含まれうるからです。

`ARG_VALUE_IN_SET` / `ARG_VALUE_IN_PAREN`

ARG_VALUE_IN_SET: / ... /x
ARG_VALUE_IN_PAREN: / ... /x

これらのターミナルは、そうした曖昧さを解決するために作られた、非常に複雑な正規表現で定義されています。その主な役割は、「ここからここまでが単一の引数（または set コマンドの値）である」という範囲を、可能な限り長く、貪欲に（greedily）読み取ることです。

この解析を実現するため、正規表現内ではいくつかの工夫が凝らされています。まず、^. のようなエスケープ文字や "(...)" といった引用符で囲まれた部分を優先的に一つの塊として解釈します。さらに set コマンドの値 (ARG_VALUE_IN_SET) では、SQL文でよく使われる <> のような記号がリダイレクトと誤認されないよう、特定のパターンが許容されています。一般的なコマンドの引数 (ARG_VALUE_IN_PAREN) では、行末、リダイレクト演算子、または連結演算子の手前までを引数として切り取るように動作します。

rem ARG_VALUE_IN_PAREN が "Hello > World" 全体を引数として解釈する
echo "Hello > World"

rem ARG_VALUE_IN_SET が "select * from T where F <> 'A'" 全体を値として解釈する
set SQL="select * from T where F <> 'A'"

さらに、MS-DOSの動作では、丸括弧 ( ) で囲まれた部分ではコマンド引数の解釈方法が変わり、引数内に存在する丸括弧のペアは引数の一部として解釈されますが、丸括弧閉じ ) だけのときは引数の一部として解釈されないような動作となります。そのため、丸括弧 ( ) で囲まれていないトップレベルのコマンドに渡されるコマンドライン引数は ARG_VALUE_IN_PAREN_TOPLEVEL ルールで定義し、丸括弧 ( ) に囲まれているコマンドに渡されるコマンドライン引数は ARG_VALUE_IN_PAREN ルールとして定義しています。コマンドも同様に、トップレベルでコマンドが呼ばれるため丸括弧を無視して解析する command_set_toplevel ルールと、丸括弧 ( ) の中でコマンドが呼ばれるので丸括弧を考慮して解析する command_set の2種類が用意されています。ここでは set コマンドを例に説明していましたが、他のコマンドも同様です。

参考資料

tex2e/msdos-cmd-parser: MS-DOS Command Parser

AIが情報を要約する現代において私たちが記事を書く意味とは

Mon, 03 Nov 2025 00:00:00 +0000

最近はAIに聞けばなんでも答えてくれる時代になりました。 AIに指示すれば自動で情報収集も行ってくれます。その影響だと思われますが、この技術ブログへのアクセス数（アクティブユーザー数）は前年比で2025年は30%減となりました。

昔は、別の人の記事では技術的な説明がとても読みにくい書き方をしているから、自分の観点で書き直して読みやすくしたものをアップロードしよう、というモチベーションがあったのですが、今ではもうAIが勝手に読みやすくしてくれるから自分がやる必要性はないよね、という気持ちで見ています。ブログ記事を書いたとしても、あくまで自分専用の備忘録として更新し続けることくらいしかモチベーションはありません。もともとブログを始めたきっかけは、自分の備忘録を書きたかったからでした。誰かに分かりやすく伝えるよりも、数年後の自分のために説明することを目的とし、それはまるで未来の自分への手紙、という意味を込めてこのブログのアイコンは紙飛行機のアイコンを採用しています。

さて、本題に入りますが、AIが情報を要約して人間の質問に回答してくれる現代において、私たちが記事を書く意味とは何だと思いますか。私は、AIではできないことで、人間にしかできないことを文章に落とし込むことが、私たちが記事を書き続ける意義だと思っています。人間にしかできないこと、それは感情や共感、経験や体験、そしてこの社会や世界に対する考察や洞察、そしてそこから生まれるコミュニティの輪などがあります。読者が本に夢中になるとき、それはポジティブ心理学におけるフロー状態であり、新しいことへのチャレンジに対する不安を取り除くためにその活動に専念・集中したり、認知的なズレから生まれる好奇心を満たすための活動であったりします。好奇心は認知のズレが大きすぎると拒絶反応に変わり、逆にズレが小さすぎると退屈になるので、そこを見極められるのは人間（著者や編集者）の力量だと思っています。また、自己効力感を高めるためにバンデューラが提唱する方法の1つである「代理経験」や「言語的説得」は、経験や感情に対する共感から来るものです。 AIから言われるよりも、自分の信頼している人から言われるときのほうが、この効果は大きいはずです。非認知能力の好奇心や情動知能の向上は、AIだけで完結できるものではありません。共感的な態度で育てられなかった子供は問題行動を起こすように、その文章に血肉が通っていなければ読み手に何も伝えることができません。

単なる知識の提供だけではAIと同じです。人間らしい文章は、感情を共感し、経験や体験を共有し、社会や世界に対する考察や洞察を落とし込み、同じ仲間を見つけてコミュニティーを作ることができるものです。その試行錯誤のプロセスを高速で回すためにAIを使うのが、私が考える、AIとの理想的な共生社会です。著者自身の経験、洞察、専門性に基づいた「オリジナルな価値」を付与した記事こそ、要約されずに読まれるような文章になると思います。例えば、その技術を採用したことでチーム内のコミュニケーションがどう変わったかとか、単なるライブラリのインストール手順ではなく、導入時に発生したエラーとその解決方法で工夫した探索プロセスなどを書くと、読者は自分ごととして捉えるようになります。

AIの台頭に不安を感じる人は多いことと思いますが、私たちが今後どこに価値を置いて情報発信すべきかの参考になれば幸いです。皆さんのよいAIライフをお祈りしております。

晴耕雨読

Visual Studioのマルチカーソル機能のカスタマイズ

キーボードショートカットの確認・変更

AES-NI 命令を用いた AES-128 暗号化の実装方法

必要なヘッダと型定義

AES-128 鍵拡張 (Key Expansion) の実装

AES 暗号化 (ECBモード) の実装

テスト実行と結果の確認

コンパイルと実行

CPUID命令を利用してCPUがAES-NIに対応しているか確認する方法

CPUIDを利用した判定プログラム

実装例 (check_aes.c)

コンパイルと実行

(補足) コマンドラインで確認する方法

AIと生きる：思考を止めるな、加速させよ

AI依存と認知的負債

思考を加速させるための視点

AIとの付き合い方

参考資料

NuGetパッケージのキャッシュをクリアする方法

1. Visual Studioでクリアする方法

2. dotnetコマンドでクリアする方法

楕円曲線 NIST P-256 と secp256r1 の違い

楕円曲線の係数を定義する団体

SECG

ANSI

NIST

RFC 8422 での定義

AIに「異能たちの会議」をさせる

異能たちの会議の作成プロンプト

2025年振り返り

仕事面

プライベート面

おわりに

[Python] LarkでMS-DOSコマンドの構文解析

1. Larkと文法定義

2. Larkの書き方

基本的なEBNF記法

具体的なルールの例

エントリーポイント

IF文

複雑な引数を捉える正規表現

3. Larkの便利な機能

4. grammar.lark 詳細解説

4.1 スクリプトの基本構造

program

line と label

4.2 制御フロー

command_line (コマンド連結)

pipeline (パイプライン)

group (コマンドのグループ化)

4.3 ステートメント

statement_if

statement_for

4.4 基本コマンド

command_set

command_echo

command_call / command_goto

command_exe

4.5 リダイレクト

4.6 最も複雑なルール：引数と値

ARG_VALUE_IN_SET / ARG_VALUE_IN_PAREN

参考資料

AIが情報を要約する現代において私たちが記事を書く意味とは

4. `grammar.lark` 詳細解説

`program`

`line` と `label`

`command_line` (コマンド連結)

`pipeline` (パイプライン)

`group` (コマンドのグループ化)

`statement_if`

`statement_for`

`command_set`

`command_echo`

`command_call` / `command_goto`

`command_exe`

`ARG_VALUE_IN_SET` / `ARG_VALUE_IN_PAREN`