- Ornithは期待外れだった
- DuckDuckGo MCPという翼
- RC4廃止について調査してほしい
- こいつ、本当に調べている
- 3分後に出てきたもの
- 経営層向け要約
- インフラ担当者向け技術的解説
- Ornithはコーダーではなく調査官だった
- EOKの壁の向こう側
- 社内調査員という現実解
- MCPという翼のために生まれた機体
Ornithは期待外れだった
正直に言う。
最初の印象は、あまり良くなかった。
私はOrnith 1.0 9Bを、主にコーディング用途で試していた。
カンバンボード。
案件管理アプリ。
業務システム。
最近の私は、Claude CodeやCodexにかなり毒されている。
「こういうものを作ってほしい」
そう伝えると、ある程度形になったものが返ってくる世界に慣れてしまっていた。
だから当然、Ornithにも同じことを期待した。
しかし結果は苦しかった。
少なくとも、私の用途では。
カンバンボードは満足に組み上がらない。
業務アプリも厳しい。
UI設計も弱い。
9Bモデルとしては頑張っている。
だが、Claude CodeやCodexと同じ土俵で評価すると、どうしても物足りなさが残る。
もっとも、私がそう考えたのも無理はない。
Ornithは発表時からSWE-Benchのスコアを大きく打ち出していた。
Agentic Coding。
自律的な問題解決。
ベンチマークの数字だけ見れば、期待してしまうのは当然だろう。
だから私は、
「思ったほどではないな」
という印象を持った。
ところが。
ある日、その評価がひっくり返る出来事が起きた。
RC4廃止について調査してほしい。
そう頼んだ時だ。
DuckDuckGo MCPという翼
少し前に、私はDuckDuckGo MCPについて記事を書いた。
ローカルLLMにWeb検索を与えるための仕組みだ。
当時の関心はシンプルだった。
ローカルLLMは便利だ。
だが、知識には限界がある。
いわゆるEOK（End Of Knowledge）の壁だ。
今日のニュースは知らない。
最新の製品情報も知らない。
新しく公開された脆弱性も知らない。
だから私は、
「ローカルLLMにWeb検索を与えると何が起きるのか」
を検証していた。
結果は面白かった。
Searchはできる。
Fetchもできる。
しかし、使い勝手を決めていたのはMCPではなかった。
モデルだった。
Gemmaは読む。
Qwenは勢いでまとめる。
gpt-ossは悩む。
同じ検索ツールを与えても、モデルごとにまるで性格が違った。
当時の私は、
「なるほど。結局はモデル次第なのだな」
と思っていた。
それは間違っていなかった。
だが、決定的に足りない視点があった。
私はその時、
MCPを単なる追加装備だと思っていた。
飛行機に後から翼を付けるようなものだと。
ローカルLLMという機体があり、
そこへDuckDuckGo MCPという便利な部品を追加する。
そんな認識だった。
しかし今は違う。
Ornithを見ていると、むしろ逆に思える。
MCPという翼を使うために設計された機体がある。
そして、その最初の実例になったのが、RC4廃止の調査だった。
RC4廃止について調査してほしい
きっかけは、RC4廃止の話だった。
Microsoftが進めているKerberos認証基盤の整理について調べていた時だ。
RC4そのものは昔から知られている暗号だ。
だから単純に、
「RC4廃止について教えて」
と聞いても、あまり面白い話にはならない。
おそらく、
RC4は古い。
AESへ移行しましょう。
Kerberosで使われています。
そんな説明で終わる。
私が知りたかったのはそこではなかった。
興味があったのは、
なぜMicrosoftが今になってRC4を切ろうとしているのか。
という点だ。
そこで、少し意地の悪い問いを作った。
RC4廃止について調査してください。
一般的な暗号理論の解説ではなく、Microsoft環境の運用リスクとして分析してください。
特に以下の観点を重視してください。
Active Directoryへの影響
Kerberos認証への影響
RC4-HMAC (etype 23) の扱い
Microsoftが近年RC4排除を進めている背景
Kerberoasting攻撃との関係
Windows Serverおよびドメイン環境で想定される障害
古いNAS、複合機、Linux Samba、Javaアプリなどへの影響
システム管理者が確認すべきポイント
移行時の現実的な対応策
また、
「RC4という暗号が危険である」
という視点ではなく、
「企業が20年以上維持してきたWindows認証基盤の技術的負債をMicrosoftが整理し始めた」
という視点で整理してください。
最新のMicrosoft公式情報やセキュリティベンダーの情報を優先し、
経営層向けの要約と、
インフラ担当者向けの技術的解説を分けてまとめてください。ポイントは一つだけだ。
RC4を暗号として見るな。
Windows認証基盤の技術的負債として見ろ。
という視点を与えた。
Active Directory。
Kerberos。
サービスアカウント。
Samba。
NAS。
Java。
単なる暗号理論ではなく、
企業の運用現場で何が起きるのかを調べてほしかった。
そして、Ornithに投げた。
正直、この時点ではそこまで期待していなかった。
検索して、
それっぽくまとめて終わるだろう。
そんな程度の予想だった。
だが、ログを見始めて少し様子がおかしいことに気付く。
こいつ、本当に調べている
最初は気にも留めていなかった。
ローカルLLMのTool Useは、これまで何度も見てきた。
検索する。
ページを読む。
要約する。
それ自体は珍しくない。
だから最初は、
「ああ、検索しているな」
くらいにしか思っていなかった。
ところがログを眺めているうちに、妙な違和感が出てきた。
search
search
fetch
fetch
search
fetchもちろん、これだけなら普通だ。
問題はその内容だった。
こいつ、
手当たり次第にFetchしていない。
のである。
もし単純なTool Useなら、
search
↓
1件目 fetch
↓
2件目 fetch
↓
3件目 fetch
↓
4件目 fetch
↓
5件目 fetchみたいな動きになる。
人間が検索結果を全部開いているようなものだ。
コンテキストはすぐ溢れる。
256Kあっても足りない。
64Kなら一瞬だ。
ところがOrnithは違った。
検索結果を見ている。
比較している。
そして必要そうなものだけ読みに行っている。
少なくとも、そうとしか思えない挙動だった。
私が驚いたのは検索能力ではない。
判断能力だ。
検索するAIは珍しくない。
FetchできるAIも珍しくない。
だが、
どれを読むべきか判断できるAIは意外と少ない。
そして、その差は想像以上に大きい。
考えてみれば当たり前だ。
Googleが価値を持ったのは、
インターネット上の全ページを読めたからではない。
読むべきページを見つけられたからだ。
情報の世界では、
読む能力より、
選ぶ能力の方が価値が高い。
そして私は、
少し前の記事でこんなことを書いていた。
「検索できること」と「読めること」は別だ。
そして、その差を埋めているのはツールではなくモデルの癖だ。
その時は半分理屈だった。
しかし今回、目の前でそれを見せつけられた。
OrnithはDuckDuckGo MCPを使っていた。
だが私が見ていたのはMCPではない。
情報収集の判断そのものだった。
そして数分後、
さらに驚くことになる。
3分後に出てきたもの
そして数分後。
レポートが返ってきた。
正確には、3分も掛かっていなかったと思う。
私は最初、
どこかで見たようなRC4解説が出てくると予想していた。
RC4は古い。
AESへ移行しましょう。
Kerberosで使われています。
セキュリティ上の理由で廃止されます。
そんな話だ。
ところが違った。
最初に目に飛び込んできたのは、
Active Directoryだった。
次にKerberoasting。
さらにSamba。
NAS。
Javaアプリケーション。
サービスアカウント。
そして移行手順。
私は少し笑ってしまった。
おいおい。
そこまで行くのか。
以下はその出力である。
RC4廃止とWindows認証基盤の技術的負債整理
経営層向け要約
何が起きているか
Microsoftは2026年1〜7月にかけて、Active Directory環境で使用されてきたKerberos認証の暗号方式「RC4」を段階的に排除する政策を変更しました。これは単なるセキュリティ強化ではなく、20年以上にわたってWindowsドメイン環境で維持されてきた互換性技術的負債の整理です。
なぜ今なのか — 経営判断が必要な理由
| 項目 | 内容 |
|---|---|
| 法的/規制リスク | 米上院議員Ron WydenがFTCにMicrosoftのセキュリティデフォルトについて調査を要請（2024年） |
| インシデント事例 | 2024年5月、米国最大病院グループAscension HealthがKerberoasting攻撃で侵害（140病院・患者データ560万人影響） |
| 金融セクター | 金融機関の65%が2024年にランサムウェア被害に遭い、平均回復コストは590万ドル |
| 技術的負債 | Windows Server 2003以降に作成された約1.7億個のアカウントでRC4フォールバックが存在していたと推定 |
タイムライン（2026年）
- 1月13日: Auditモード開始 — 「問題がある場所」を可視化
- 4月14日: Enforcementモード開始 — RC4依存サービスが認証停止する可能性
- 7月: 永久強制化 — リロールバック不可、RC4は明示的に許可されたアカウントのみに限定
経営層へのメッセージ
「2026年4月から、過去に作成した無数なサービスアカウントやデバイスが突然動作しなくなるリスクがある。」
これは「セキュリティアップデート」ではなく「認証基盤の暗号方式変更」であり、影響範囲は組織内のすべてのKerberos利用者が対象です。早期のインベントリと移行計画策定が必要です。
インフラ担当者向け技術的解説
背景：RC4がなぜ問題なのか（企業視点）
Windows環境では20年以上にわたり「AES-SHA1が使えない古いデバイスはRC4で対応する」という互換性設計が維持されてきました。この設計の技術的負債が、最近のGPU性能向上とKerberoasting攻撃手法の普及により顕在化しています。
CVE-2026-20833 (CVSS 5.5) — KerberosプロトコルでRC4-HMACをデフォルトで使用されることで、局所的な攻撃者が認証情報を容易にクラックできる情報漏洩リスクを特定しました。ただしMicrosoftはこれを「脆弱性」としてではなく、「RC4の排除を進めるための契機」と位置づけています。
3段階タイムラインの詳細
Phase 1: Audit Mode（2026年1月13日以降）
Windows Server 2019以降のDCにKB5073381を適用すると、SystemログにKDCSVCイベントID 201〜209が追加されます。認証動作自体は変更されず、監視用です。
| イベントID | 意味 | ロギング位置 |
|---|---|---|
| 201 | クライアントがRC4のみを広告（サービスが明示設定なし） | Systemログ KDCSVC |
| 202 | サービスアカウントにAES鍵材料がない | Systemログ KDCSVC |
| 203 | Enforcement時：認証拒否（201のブロック版） | Systemログ KDCSVC |
| 204 | Enforcement時：認証拒否（202のブロック版） | Systemログ KDCSVC |
レジストリキー: HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System\Kerberos\Parameters\RC4DefaultDisablementPhase
- 値1 = Auditのみ（デフォルト）
- 値2 = April Enforcementの動作をシミュレート可能
Phase 2: Enforcement with Rollback（2026年4月14日以降）
DefaultDomainSupportedEncTypes (DDSET) のデフォルトが RC4を含む → AES-SHA1のみ (0x18) に変更されます。明示的にAESを許可していないアカウントの認証がブロックされるようになります。ただし、レジストリキーでロールバック可能（値1に戻す）。
Phase 3: Permanent Enforcement（2026年7月以降）
RC4DefaultDisablementPhase レジストリキーが削除され、ロールバック不可。明示的に msDS-SupportedEncryptionTypes = 0x1C (28) に設定されているアカウントを除きRC4は完全に無効化されます。
Active Directoryへの影響の詳細
msDS-SupportedEncryptionTypes のビット値と対応
| 値(Decimal) | 値(Hex) | 暗号方式 | Phase2以降の挙動 |
|---|---|---|---|
| 0 / null | 0x0 | デフォルト適用 | ブロック可能 ← 最も危険な状態 |
| 4 | 0x4 | RC4-HMACのみ | ブロック |
| 8 | 0x8 | AES128-SHA96 | OK（AES対応） |
| 16 | 0x10 | AES256-SHA96 | OK |
| 24 | 0x18 | AES128+AES256 | 推奨目標値 |
| 28 | 0x1C | AES+RC4 | 一時的許容（例外として） |
最も問題となるケース：「msDS-SupportedEncryptionTypesが未設定のアカウント」
- Windows Server 2003以前に作成されたサービスアカウントで、以降パスワードリセットが行われていない
- 「属性が空白（null）」状態 → DDSETデフォルトに依存 → Phase2以降はRC4フォールバックが消えるため認証停止するリスクあり
- 特に注意：FSLogix VDIプロファイル用コンピューターアカウントもこのカテゴリーに該当
Kerberos認証への影響の深掘り
etype（暗号方式タイプ）の交渉フロー
Client ──[AS-REQ/AS-RPQ]──→ KDC
│ │
├── Advertised Etypes: │ msDS-SupportedEncryptionTypes (アカウント)
│ RC4, AES128, AES256 ├── DDSET (ドメインデフォルト)
│ │
└── Session Key Selection:│
KDCが最も強い共通暗号を
セッションキーとして選択
ポイント:
- 以前はKDCがRC4を選択していた（互換性優先）
- Phase2以降：KDCは明示的に設定されていない場合はAES-SHA1のみを選択
- RC4-HMAC (etype 23) のみで動作するアプリケーションは認証不能に
Keytabファイルの問題
Linux/Unix環境でkrb5.confやキータブファイルがRC4暗号方式（rc4-hmac, aes256-cts-hmac-sha1-96, 混在）で生成されている場合、Phase2以降に認証拒否が発生します。特に問題なのは：
- Javaアプリケーションの
krb5.ini:permitted_enctypes = rc4-hmac aes256-cts-hmac-sha1-96のようにRC4が明示的に許可されている設定 - Linuxホストのキータブファイル（
ktpassやsamba-toolで生成）
RC4-HMAC (etype 23) の扱いの詳細
Phase3以降、明示的に設定されていないアカウントはRC4-HMACを一切使用できなくなります。これは：
- Kerberoasting攻撃の脆弱性: RC4チケットはAESチケットに比べてGPUクラックで約100万分の1の時間で解読可能
- Golden Ticket攻撃: RC4鍵材料からの偽チケット作成が容易化
- GSS-API/SPNEGO: Windows interopでRC4-HMACを使用するサードパーティライブラリも影響
例外プロセス: stillneedrc4@microsoft.com にメール送信（ドメイン名、影響サービスアカウント、移行タイムラインを記載）→ Microsoft CSSチームが審査し、仮のグローバルポリシー例外を提供（一時的な回避策）。
Windows Serverおよびドメイン環境で想定される障害
| シナリオ | 影響 | 詳細 |
|---|---|---|
| Service Account認証破損 | 致命的 | RC4鍵材料なし + DDSETがAESのみ → TGS取得不能 |
| SMB共有/NAS接続 | 中程度〜致命的 | NASのコンピューターアカウントがRC4依存 → 共有不可 |
| FSLogix VDIプロファイル | 致命的（VDI環境） | コンピューターアカウントのKerberos認証でSMBストレージにアクセスし、Profile Containerの読み込み失敗 |
| Java/Tomcat/JBoss/WebLogic | 致命的可能性 | krb5.ini でRC4がpermitted_enctypesに含まれる場合、接続拒否 |
| 複合機/プリンター | 中程度 | Windows Print ServicesでRC4キータブを使用している場合 |
| SQL Server接続 | 致命的 | Service BrokerやAlwaysOn HAでKerberosを使用するサービスアカウントが影響 |
| Linux/macOSクライアント | 中程度〜致命的可能性 | Kerberosライブラリが旧版（RC4のみ対応）の場合 |
古いNAS、複合機、Linux Samba、Javaアプリへの影響の深掘り
NAS/SMBストレージ
Samba-based NAS（Synology、QNAP、Asustorなど）はWindowsドメインに参加しKerberos認証で共有アクセスしています。これらの機器は：
- 設定で明示的にRC4を許可していないことが多い
- コンピューターアカウントがDDSETのデフォルトに依存
- Phase2以降に共有へのKerberosアクセスが拒否される可能性あり
Linux Samba環境
Samba 4.24（2026年3月18日リリース）でCVE-2026-20833がパッチ済み。ただし：
- Windows Server 2008以上のドメイン機能レベルのみAESデフォルトに切り替わる
- ドメインが旧機能レベル（Windows 2003等）の場合、旧動作維持
- smb.confの
kdc default domain supported enctypesパラメータを手動で設定する必要がある場合あり
ini# smb.conf の変更例
[global]
kdc default domain supported enctypes = aes128-cts-hmac-sha1-96 aes256-cts-hmac-sha1-96
kdc default realm supported enctypes = aes128-cts-hmac-sha1-96 aes256-cts-hmac-sha1-96
Java/Tomcat/WebLogic/JBoss
JavaのKerberos実装（JAAS/GSS）で krb5.ini の設定が：
ini# 旧設定（問題あり）
[libdefaults]
default_tkt_enctypes = rc4-hmac aes256-cts-hmac-sha1-96
default_tgs_enctypes = rc4-hmac aes256-cts-hmac-sha1-96
permitted_enctypes = rc4-hmac aes256-cts-hmac-sha1-96
# 新設定（推奨）
[libdefaults]
default_tkt_enctypes = aes256-cts aes128-cts
default_tgs_enctypes = aes256-cts aes128-cts
permitted_enctypes = aes256-cts aes128-cts
注意: JavaのKerberosライブラリ（Sun/Oracle JDK, IBM JRE, OpenJDK）はバージョンによってRC4対応が異なり、古いライブラリではAESのみで動作しない場合があります。
複合機/プリンター
多くのビジネス用印刷装置はWindowsドメインに参加し、Kerberos認証でジョブキューにアクセスしています。特に問題となるのは：
- キータブファイルがRC4暗号方式で生成されている場合
- 機器のOSバージョンがWindows Server 2003以前（AES-SHA1非対応）の場合
システム管理者が確認すべきポイント
必須チェックリスト
powershell# 1. RC4依存アカウントの特定
Get-ADUser -Filter {ServicePrincipalName -ne $null} -Properties msDS-SupportedEncryptionTypes |
Where-Object { $_.'msDS-SupportedEncryptionTypes' -band 0xC } |
Format-Table SamAccountName, 'msDS-SupportedEncryptionTypes', ObjectClass
# 2. RC4鍵材料がないアカウントの特定（List-AccountKeys.ps1を使用）
.\List-AccountKeys.ps1 |
Where-Object { $_.Keys -notcontains "AES" } |
Format-Table Time, Name, Type, Keys
# 3. KDCSVCイベントでRC4使用を検出（Systemログ、KDCSVCソース）
Get-WinEvent -FilterHashtable @{LogName='System'; ProviderName='Kerberos Key Distribution Center Service'} |
Where-Object { $_.Message -match '201|202' }
# 4. DefaultDomainSupportedEncTypesの確認
$regValue = Get-ItemProperty "HKLM:\SYSTEM\CurrentControlSet\Control\Lsa\Kerberos\Parameters"
"$($regValue.DefaultDomainSupportedEncTypes) ($('0x{0:X}' -f [int]$regValue.DefaultDomainSupportedEncTypes))"
# 5. KRBTGTアカウントのmsDS-SupportedEncryptionTypes確認（AES鍵材料があるか）
Get-ADAccount -Identity "KRBTGT" -Properties msDS-SupportedEncryptionTypes |
Select-Object SamAccountName, 'msDS-SupportedEncryptionTypes'
監査スクリプト（Microsoft公式提供）
GitHubリポジトリ: https://github.com/microsoft/Kerberos-Crypto
- List-AccountKeys.ps1: イベントログからアカウントの鍵材料を列挙
- Get-KerbEncryptionUsage.ps1: Kerberos使用状況を確認（
-Encryption RC4でフィルタ）
移行時の現実的な対応策
優先順位付き対応フロー
┌─────────────────────────────────────────────┐
│ 1. インベントリ取得（2週間以内） │
│ - List-AccountKeys.ps1 / Get-KerbEncryptionUsage.ps1
│ - KDCSVCイベント201/202のログ解析 │
│ - NAS/Samba/JAVA環境の特定 │
├─────────────────────────────────────────────┤
│ 2. Service Account修正（本番前） │
│ - msDS-SupportedEncryptionTypes = 24 (0x18) │
│ - パスワードリセット（AES鍵材料生成のため） │
│ ※ 一度では不十分 → 2回連続でリセット推奨 │
├─────────────────────────────────────────────┤
│ 3. レガシー環境の移行 │
│ - Java: krb5.ini更新 + keytab再エクスポート │
│ - Linux Samba: smb.conf修正 + リスタート │
│ - NAS: キータブ更新 + 共有アクセステスト │
│ - プリンター: 機器メーカーサポート確認 │
├─────────────────────────────────────────────┤
│ 4. テスト環境でのロールバックシミュレーション │
│ - RC4DefaultDisablementPhase = 2 │
│ - フルビジネスサイクルの認証テスト │
└─────────────────────────────────────────────┘
April 14 (Enforcement) ────> 本番環境へ適用
具体的な操作例：Service Accountの修正
msDS-SupportedEncryptionTypesの設定:
powershell# 各サービスアカウントにAES設定を適用（0x18 = 24）
Set-ADUser -Identity "svc_app" -Replace @{msDS-SupportedEncryptionTypes=24}
Set-ADComputer -Identity "VM01$" -Replace @{msDS-SupportedEncryptionTypes=24}
# RC4が明示的に許可された状態（例外として）の場合は:
# Set-ADUser -Identity "svc_legacy" -Replace @{msDS-SupportedEncryptionTypes=28}
パスワードリセット:
powershell# AES鍵材料を生成するため
Reset-ADAccountPassword -Identity "svc_app" -Force
# 2回連続で実行（リプリケーションのため）
Reset-ADAccountPassword -Identity "svc_app" -Force
Keytabの再エクスポート:
bash# Linux環境で、新しいAES鍵材料を含むkeytabを生成
ktpass -out svc_app.keytab -princ svc_app@CONTOSO.COM \
-mapuser svc_app$ -ptype KRB5_NT_PRINCIPAL \
-crypto AES256-CTS-HMAC-SHA1-96 \
-pass *password*
# krb5.iniの更新
[libdefaults]
default_tkt_enctypes = aes256-cts aes128-cts default_tgs_enctypes = aes256-cts aes128-cts
リスク緩和策：例外申請プロセス
Microsoftは stillneedrc4@microsoft.com にメール送信することで、一時的なグローバルポリシー例外を取得できます。ただしこれは永続的な解決ではなく、移行タイムラインを明確に示す必要があります。
技術的負債整理の視点からの補足
このRC4廃止は、MicrosoftがWindowsドメイン環境で20年以上にわたって維持してきた「AES-SHA1が使えないレガシーデバイスをRC4フォールバックで対応する」設計上の妥協を、技術的な正当性がなくなったこと（GPUクラックの容易化）と、セキュリティインシデントの増加を理由に整理し始めたことを示しています。
企業にとっては「20年以上前に設定した互換性要件が、最近になって強制終了される」という状況であり、これは：
- 技術的負債の可視化: 過去に無視できたRC4依存が、セキュリティ脅威の高まりによって顕在化した
- 設計上の不備の整理: 「とりあえず動く」前提の互換性設計を、セキュリティ要件として見直す
- 移行コストの発生: レガシー環境の置換・更新に伴う開発・運用コストが発生する
経営層には「技術的な問題」というより「20年以上先送りにしてきたセキュリティ投資の回収」と理解いただければと思います。
ここまでですべて。
もちろん完璧ではない。
事実確認も必要だ。
細部に怪しい箇所もあるかもしれない。
しかし重要なのはそこではない。
RC4という単語から、
Active Directory運用へ飛んだ。
Kerberosから、
サービスアカウントへ飛んだ。
そして、
Windows認証基盤というテーマに収束していた。
つまり、
私がプロンプトで与えた視点を理解していた。
いや、
理解という表現は少し違う。
追跡していた。
Microsoftはなぜ今RC4を切るのか。
その問いに答えるために、
必要な情報を探し、
必要なページを読み、
そして整理していた。
ここで初めて気付いた。
私は今まで、
Ornithをコーディングモデルとして見ていた。
しかし目の前で起きていることは、
コーディングとはまるで違う。
これは調査だ。
新人エンジニアに
「RC4廃止について調べてきて」
と頼んだ時の動きに近い。
まず検索する。
知らない単語を調べる。
別の資料を読む。
話を繋げる。
そして報告書を作る。
私が見ていたのは、
コード生成ではなかった。
情報収集だった。
そしてその瞬間、
これまで抱いていたOrnithの評価が少しずつ変わり始めた。
Ornithはコーダーではなく調査官だった
私はずっと勘違いしていた。
Ornithをコーディングモデルとして見ていた。
それも無理はない。
発表時から強調されていたのはSWE-Benchだった。
Agentic Codingだった。
ベンチマークの数字だった。
だから私も、
「どこまでアプリを作れるのか」
という視点で見ていた。
カンバンボード。
案件管理アプリ。
業務システム。
そういう評価軸だ。
そして、その評価は決して間違いではなかったと思う。
実際、AIエージェント時代においてコーディング能力は重要だ。
だが今回の検証で気付いた。
私はエンジンを見ていなかった。
車体を見ていたのだ。
Claude CodeやCodexが優秀なのは、
コードを書けるからではない。
調べるからだ。
エラーメッセージを読む。
ドキュメントを探す。
GitHubを探る。
ライブラリを比較する。
そして必要なものを選び取る。
実際の開発現場では、
コードを書いている時間より、
調べている時間の方が長いことすらある。
今回のRC4レポートで見えたのは、
その部分だった。
私は最初、
OrnithをClaude CodeやCodexの代用品として見ていた。
しかし今は少し違う。
むしろ、
Claude CodeやCodexを動かすためのエンジンに近い。
検索する。
読む。
比較する。
整理する。
その一連の流れに妙な強さがある。
そして気付いてしまった。
カンバンボードが作れなかったことと、
RC4レポートが優秀だったことは、
実は矛盾していない。
どちらも同じ能力を測っているわけではないからだ。
カンバンボードを作るには、
UI設計が必要だ。
状態管理も必要だ。
ユーザー体験も必要だ。
一方でRC4レポートに必要なのは、
情報探索能力だ。
何を調べるべきか。
何を読むべきか。
何を捨てるべきか。
私はその時ようやく理解した。
Ornithが得意なのは、
コードを書くことではない。
世界を調べることなのだ。
そして、それはローカルLLMにとって思っていた以上に大きな意味を持っていた。
EOKの壁の向こう側
ローカルLLM最大の弱点は、長い間変わらなかった。
EOK。
End Of Knowledge。
知識の終端だ。
どれだけ優秀なモデルでも、
学習していないことは知らない。
今日発表された脆弱性。
昨日公開された製品。
さっき出たニュース。
それらは分からない。
だからRAGが流行った。
PDFを読み込ませる。
社内文書を読み込ませる。
マニュアルを検索させる。
実際、それは非常に実用的だった。
今でも企業利用においてRAGは重要な技術だ。
しかし副作用もあった。
ローカルLLMは次第に、
「賢い検索窓」
として扱われるようになった。
質問する。
文書を検索する。
答えを返す。
それは便利だった。
だが、どこか閉じていた。
検索対象は社内文書。
検索対象は登録済みデータ。
検索対象は事前に準備された知識。
つまり、
世界そのものは見ていない。
ところが今回、
私は少し違うものを見た気がした。
RC4について調べろ。
そう言われたOrnithは、
社内文書を探し始めたわけではない。
Webを探した。
情報を比較した。
別の資料を読んだ。
そして報告書を作った。
これはRAGとは少し違う。
知識庫を検索するエンジンではない。
世界を調査するエンジンだ。
もちろん、
まだ万能ではない。
コンテキストは有限だ。
Fetchし過ぎれば溢れる。
256Kあっても無限ではない。
だから判断力が重要になる。
何を読むか。
何を読まないか。
その能力がなければ、
検索できても意味がない。
しかし逆に言えば、
ローカルLLMは今、
初めてEOKの壁の向こう側を見始めている。
そしてここで、皮肉なことが起きる。
私は今回の検証で、
Ornithの価値を再発見した。
だが同時に、
GPTやGemini、そしてClaudeの価値も再発見した。
なぜなら、
今回のRC4調査を生んだ最初の問い。
「RC4という暗号ではなく、
Windows認証基盤の技術的負債として見ろ」
という視点そのものは、
GPTとの対話の中から生まれたものだったからだ。
調査するAI。
検索するAI。
整理するAI。
その価値は確かに大きい。
だが、
何を調べるべきなのか。
どこに価値があるのか。
どの視点で世界を見るべきなのか。
そこには依然として、
フロンティアモデルの強みがある。
だから私は今回、
ローカルAIがクラウドAIを置き換える未来を見たわけではない。
むしろ逆だ。
問いを作るAI。
調査するAI。
実行するAI。
それぞれの役割が少しずつ分かれ始めている。
そして、その先に見えてきたのは、
ローカルLLMの新しい居場所だった。
社内調査員という現実解
今回の検証を見ていて、私は以前考えていた「社内相談窓口としてのAI」を思い出した。
ただ、少し見方が変わった。
当時イメージしていたのは、考えを整理する相手だった。
壁打ち相手。
相談相手。
アイデアを広げる相手。
そういう存在だ。
しかし今回見えたのは、もう少し実務寄りの姿だった。
RC4廃止の影響は？
この脆弱性は自社に関係ある？
この製品のライセンスは問題ない？
この発表の要点は？
企業には毎日こうした問いが発生する。
そして、その多くは、
「専門家を呼ぶほどではないが、誰かに調べてほしい」
種類のものだ。
今回のOrnithは、まさにそこに収まる。
完璧な専門家ではない。
もちろん最終判断を任せられる存在でもない。
だが、
調べる。
読む。
整理する。
報告する。
その能力は十分に実務的だった。
ここで重要なのは、私はこれを業務システムの基盤にしようと言っているのではない。
判断は人間がする。
責任も人間が持つ。
それは今後もしばらく変わらないだろう。
だが、調査の初速を上げる価値は大きい。
数年前まで、ローカルLLMは文章生成のおもちゃだった。
その後、RAG検索エンジンになった。
社内文書を検索し、PDFを要約する存在になった。
それだけでも十分に実用的だった。
しかし今回見たのは、そのさらに先だ。
知らない。
だから調べる。
その行動が自然に行われていた。
しかも、単に検索結果を並べるのではない。
必要そうな情報を探し、
不要な情報を捨て、
そして報告書として整理していた。
私は今回、ローカルLLMがRAG専用機から卒業する瞬間を見た気がしている。
もちろん、まだ万能ではない。
コンテキストには限界がある。
FetchしすぎればToken Exhaustedに出会う。
だからこそ、
何を読むべきか。
何を読まないべきか。
その判断力が重要になる。
しかし、それを差し引いても。
私は久しぶりにローカルAIの未来を感じた。
MCPという翼のために生まれた機体
最初、私はこう考えていた。
OrnithがDuckDuckGo MCPという翼を手に入れた。
そういう話だと思っていた。
ローカルLLMという機体がある。
そこへ検索機能を追加する。
Webを読めるようにする。
最新情報を取得できるようにする。
そんな理解だった。
だが、今回の検証を終えた今は少し考えが違う。
Ornithは、
MCPという翼を使うために設計された機体だったのではないか。
そう思えてならない。
もちろん、コーディング能力だけを見れば、もっと優秀なモデルはある。
UI設計が得意なモデルもある。
長大なコードベースを扱えるモデルもある。
フロンティアモデルには、いまだ大きな優位性が存在する。
そして今回のRC4調査そのものも、
問いを作る段階ではGPTやGeminiとの対話が大きな役割を果たしていた。
「RC4とは何か」
ではない。
「Microsoftはなぜ今、20年以上維持してきた互換性を切ろうとしているのか」
その視点を見つける力。
問いの焦点を定める力。
そこには今もフロンティアモデルの強さがある。
だが、その問いを受け取り、
調べ、
読み、
比較し、
整理し、
報告する。
その役割ならどうだろう。
今回のOrnithは、
驚くほど自然にそれをやってみせた。
私はこの記事の冒頭で、
カンバンボードが作れなかった話を書いた。
正直、少し期待外れだった。
だが今振り返ると、
私はずっと間違った場所を見ていたのかもしれない。
Ornithは優秀なコーダーなのか。
その問いは、おそらく本質ではない。
Ornithは優秀な調査官なのか。
今の私には、その方がしっくりくる。
ローカルLLM最大の壁だったEOK。
End Of Knowledge。
知らないことは答えられない。
その常識は、まだ完全には崩れていない。
しかし今回、
私はその壁の向こう側を少しだけ見た気がした。
検索する。
読む。
考える。
報告する。
その一連の流れが、
9Bという小さなモデルの中で動き始めている。
それは単なるベンチマークの数字よりも、
ずっと未来を感じる出来事だった。
そして私は今、
久しぶりに次の検証が楽しみになっている。
