NNUE(Efficiently Updatable Neural Network)は、盤面評価に浅い層のニューラルネットワークを用いる評価関数アーキテクチャ。2018年に那須(tanuki-チーム)が考案し、将棋エンジン「やねうら王」で最初に採用された。その後チェスにも移植され、Stockfishが2020年に採用したことで西洋チェス界にも広まった。

基本原理

NNUEは「入力特徴量の非ゼロ要素が少ないこと」と「1手進むごとに入力の変化が小さいこと」という2つの性質を前提に設計されている。アルファベータ探索中は1手ごとに評価関数を何百万回も呼び出す必要があるが、NNUEは差分更新(incremental update)によって、盤面全体のニューラルネットワークを毎回フルで計算し直すのではなく、直前の評価からの変化分だけを反映してAccumulator(入力層直後の中間表現)を更新する。これにより、疎な全結合層を持つネットワークでも高速に評価値を算出できる。

アーキテクチャの典型例

入力層は玉の位置と各駒の位置の組み合わせ(King-Piece)などを特徴量としたスパースなベクトル(チェスでは768次元程度)で、Feature Transformer(FT)層と呼ばれる隠れ層(数千ユニット程度)に変換され、さらにいくつかの隠れ層を経て最終的に1つのスカラー値(評価値)を出力する。

差分更新の限界とFinny Tables

差分更新は「駒が動く」ケースには強いが、玉の位置自体が入力特徴に含まれる(King-Piece方式の)場合、玉が移動すると入力特徴が全て変わってしまい差分更新できず、盤面全体を再計算する「full refresh」が必要になる。このコストを削減する最適化がFinny Tables。

出典

• Efficiently updatable neural network - Wikipedia
• NNUE - Chess Programming Wiki
• Introducing NNUE Evaluation - Stockfish
• やねうら王 - Wikipedia

#nnue #shogi #chess #neural-network

チェス・将棋AIの評価関数NNUEにおいて、玉(キング)が移動した際のアキュムレータ(Accumulator)更新を高速化する最適化技術。「Accumulator Cache」とも呼ばれる。チェスエンジンKoivistoの開発者Finn Eggersが考案したことに由来する通称。

解決する問題

NNUEはFeature Transformer(FT)層への入力特徴量として、玉の位置と各駒の組み合わせ(King-Piece, KP)を使うことが多い。この設計(king bucketed inputs)では、駒が動いた場合は差分更新(incremental update)でFT層の出力を軽量に更新できるが、玉自体が移動して別のking bucketをまたぐと、入力特徴が全て変わってしまうため、アキュムレータ全体を再計算する「full refresh」が必要になる。この処理は通常の差分更新よりもはるかにコストが高い。

仕組み

Finny Tablesは、玉の位置(チェスなら64マス、将棋なら81マス)ごとに、過去に計算したアキュムレータとその時点の盤面のビットボードをキャッシュとして保持しておく。玉が別のking bucketへ移動してfull refreshが必要になった場面では、以下の手順で更新する。

1. 移動先の玉位置に対応するキャッシュ済みアキュムレータとビットボードを取得する
2. キャッシュ時点のビットボードと現在の盤面のビットボードとの差分(駒の増減)を計算する
3. その差分だけをキャッシュ済みアキュムレータに適用して更新する
4. 更新後のアキュムレータと現在のビットボードで、そのking bucketのキャッシュエントリを上書きする

これにより、駒の全特徴量を再計算するfull refreshを避け、差分計算だけで済ませられる。

やねうら王への実装

将棋エンジン「やねうら王」に実装された際の計測では、推論部で30〜50%の高速化、探索速度(NPS)で約15%の向上が報告されている。玉移動コストが下がったことで、FT層のユニット数を増やすなど評価精度を上げる方向の設計変更にも余地が生まれ、既存の「最適」とされてきたアーキテクチャの見直しが将棋AI開発コミュニティで進んでいる。

出典

• Finny Tablesをやねうら王に実装した - やねうら王
• NNUE - Chess Programming Wiki

#nnue #shogi #chess #search-algorithm

Rakuの構文のうちPerl5に近い部分をサブセットとして採用した言語処理系。Go言語で実装されている。GitHubユーザーxyzzyappsによる個人プロジェクトで、Reddit r/rakulangへの投稿"Announcing Raptor: a Perl5 subset of Raku"をきっかけに知った。

概要

• リポジトリ: xyzzyapps/raptor（ホームページ: xyzzyapps.github.io/raptor）
• 実装言語: Go
• ライセンス: Artistic License 2.0
• リポジトリ作成日: 2026-08-13

コンセプト

READMEでは「Post-LLM パラダイム」向けに設計した言語ランタイムと位置づけている。LLMのコンテキストウィンドウ効率を意識し、トークン密度が高く簡潔な構文を志向している。

採用しているPerl5由来の構文要素:

• $/@/%のシジル記法
• 動的型付け、Nil
• 組み込み演算子
• postfix if/forなどのステートメント修飾子
• リファレンス/デリファレンス、label/goto

一方、Rakuのclass/has/isによるオブジェクト指向のボイラープレートは採用していない。

Design by Contract志向の機能も持つ。

subset Positive where { $_ > 0 };
my Positive $balance = 100;  # OK
# $balance = -10;            # エラー

• subset ... where { ... }による述語型
• PRE/POST/INVARIANTキーワード
• 変数代入のたびに動的述語を評価する継続的不変量チェック
• QuickCheck的なプロパティベース型ファジング
• UFCS（統一関数呼び出し構文）
• C互換構造体メモリ

リポジトリには、実行系（raptor/ディレクトリ）とは別にmoarvm-go/ディレクトリがあり、MoarVM（バイトコードエミッタ、メタモデル、Raku文法エンジンなど）のGoによるホスト実装が含まれている。raptor/側にはCharmbraceletベースのTUIエンジン、TAP v13テストプロデューサー、WebAssembly対応、Gitベースパッケージマネージャなども同梱されている。

参考文献としてRobert Bruce Findlerの契約プログラミング論文、Liquid Types論文などがREADMEに挙げられている。

出典

• xyzzyapps/raptor - GitHub
• Reddit r/rakulang “Announcing Raptor: a Perl5 subset of Raku"（投稿本文・コメントは未確認）

#raku #perl #golang #compiler

SOC(System and Organization Controls)は米国公認会計士協会(AICPA)が定めた監査フレームワーク。SOC 2はその中でも、クラウドサービス・SaaSなど顧客データを扱うサービス組織の内部統制を評価する報告書で、AICPAが策定したTrust Services Criteria(信頼性サービス基準、TSC)という評価基準に基づいて監査が行われる。

Trust Services Criteria(5つの評価カテゴリ)

• Security(セキュリティ) — 不正アクセスからの保護。SOC 2監査で唯一必須のカテゴリ
• Availability(可用性) — 契約通りにシステムが利用可能であること
• Processing Integrity(処理の完全性) — 処理が完全・正確・適時であること
• Confidentiality(機密性) — 機密情報が保護されていること
• Privacy(プライバシー) — 個人情報が適切に収集・利用・保持されていること

Securityのみ必須で、残り4つは事業内容や顧客との契約に応じて対象に含めるかどうかを選択する。

Type 1とType 2の違い

• Type 1 — ある一時点でのコントロールの「設計」を評価する。監査期間の目安は3〜6ヶ月
• Type 2 — 3〜12ヶ月間の観察期間における「運用の実効性」を評価する。初回の監査期間の目安は6〜15ヶ月

Type 2の方がより厳密で、エンタープライズ顧客や規制業界から好まれる。

SOC 1・SOC 2・SOC 3の違い

• SOC 1 — 財務報告に影響する内部統制を対象(会計目的)
• SOC 2 — データ保護に関する運用リスク管理を対象。詳細で機密性の高い内容のため、NDAを結んだ顧客・見込み客にのみ開示するのが通例
• SOC 3 — SOC 2と同じ監査に基づくが、技術的詳細を省いた一般公開向けの簡易版。必ずType 2ベースで発行され、Webサイト等で公開できる

数字は難易度の序列を表すものではなく、SOC 1を取ってからSOC 2に進む必要もない。

関連ノート

SOC 2は具体的な実装手段(プルリクエストレビューの要否など)を規定しているわけではなく、リスクに対するコントロールが機能していることを求める枠組みである、という論点についてはSOC 2準拠にプルリクエストは必須ではないを参照。

出典

• SOC 2 Trust Services Criteria (TSC): A Guide | Cherry Bekaert
• 2025 Trust Services Criteria for SOC 2 | Secureframe
• SOC 2 Trust Services Criteria (TSC) Explained | Schellman
• SOC 2 Type 1 vs. Type 2: Timeline, Cost, and Key Differences | Drata
• SOC 1 vs SOC 2 vs SOC 3: What’s the Difference? | Secureframe

#soc2 #compliance #security

AIコーディングツールAmp(Sourcegraph製)のチームブログ記事「That’s not SOC 2 compliant」(著者: Will Dollman)の要旨。Ampチームはプルリクエストを使わずメインブランチへ直接pushする開発フローを採用しているが、それでもSOC 2準拠を達成しているという内容。

主張の骨子

SOC 2はプルリクエストというプロセスそのものを要求していない。求められているのは、変更に伴うリスクが「考慮され、コントロールされていること」であり、具体的な実装手段(PRレビューを必須にするかどうか)は問われない。監査人が確認するのは、リスクに対して何らかのコントロールが機能しているかどうかという実質面。

PRの代わりに導入している4つのコントロール

1. Restricted push access — ビジネス上の役割に基づいてmainへのpush権限を制限する
2. Signed commits — GitHub上で検証済み署名を必須化し、コミット作成者を検証可能にする
3. Automated CI — テスト・インフラ・セキュリティチェックを含む検証パイプラインを全pushに対して実行する
4. 監査証跡 — 各コミットを"Amp threads"(Ampとのやり取りの記録)にリンクし、変更の経緯を追跡可能にする

スケーラビリティについての著者の立場

Ampチームは現在20名規模(大半がエンジニア)で、この規模とチーム内の信頼関係があってこそ成立している面がある。著者自身も「2,000人規模の会社が全員にmainへのpush権限を与えるべきか」には否定的な立場を示している。結論として、組織やチーム全体を一律に変える必要はなく、システムごとに「PRが実際に管理しているリスクは何か」を問い直し、別のコントロールで代替できないか検討すべき、というのが記事の主張。

出典

• That’s not SOC 2 compliant - Amp

#soc2 #ci-cd #devops

サードパーティCookieやリダイレクトに頼らず、ブラウザが仲介する形でフェデレーション認証（「Googleでサインイン」のような外部IdPによるログイン）を実現するWeb標準API。Chrome/EdgeなどのPrivacy Sandbox関連APIの一つとして開発され、W3C FedID Community Groupで標準化が進んでいる。 #protocol #security #browser

背景

従来のフェデレーション認証（OAuth/OIDCベースの「〇〇でサインイン」ボタン）は、IdP（Identity Provider、認証情報を持つ側。例: Google）とRP（Relying Party、ログインを受け付けるサイト）間の連携にiframeやポップアップ、リダイレクト、サードパーティCookieを使っていた。ブラウザがサードパーティCookieを制限・廃止する流れの中で、これらの仕組みは動作しなくなる。FedCMはCookieに依存しない代替手段として設計された。

仕組み

RP側はnavigator.credentials.get()にIdPのconfigURLとclientIdを渡して呼び出す。IdP側は3層構造でエンドポイントを用意する。

• .well-known/web-identity — IdPのルートドメインに置くメタデータファイル
• Config file — accounts_endpoint・client_metadata_endpoint・id_assertion_endpoint・login_urlなどを列挙するJSON
• Accounts endpoint — ログイン中ユーザーのアカウント一覧（id・email・name等）を返す
• ID assertion endpoint — ユーザーがアカウントを選択した後、RP向けのトークンを発行する

ユーザーへのアカウント選択UIはブラウザが標準ダイアログとして描画し、IdP・RPどちらのページにも埋め込まれない。IdP側はログイン状態をnavigator.login.setStatus()やHTTPのSet-Loginヘッダーで管理する。

プロトコル非依存

FedCM自体は認証プロトコルそのものではなく、既存のOAuth/OpenID Connectサーバーの上に被せる「ブラウザ仲介レイヤー」という位置づけ。IdP側がFedCM用エンドポイントを実装し、発行したコードを既存のアクセストークン取得フローに渡すといった統合が可能。

採用状況

Googleは2024年10月にGoogle Identity ServicesのFedCM移行を完了し、2025年8月からOne Tap・サインインボタンでのFedCM利用を必須化した。LinkedIn・Reddit・Notionなど「Googleでサインイン」を使う多数のサイトが、Chrome上では実質的にFedCM経由で動作している。ブラウザ対応はChrome/Edgeが先行し、Firefox・Safariは限定的または実装予定の段階。

Email Verification Protocolとの関係

どちらも「ブラウザが第三者（IdP／メールプロバイダ）とRPの間を仲介し、Cookieや手動のやり取りなしにユーザーの身元・所有権を証明する」という設計思想を共有する。EVPはメールアドレス所有権の検証に特化した仕組みで、FedCMはより一般的なフェデレーション認証（アカウントそのものでのログイン）を扱う点が異なる。

出典

• Federated Credential Management API is shipping - Privacy Sandbox
• FedCM: A privacy-preserving identity federation API - Chrome for Developers
• Federated Credential Management (FedCM) API - MDN
• Federated Credential Management API - W3C

ブラウザが仲介してメールアドレスの所有権を暗号学的に検証する、確認メールを送らずに完了するメール確認のプロトコル。著者はDick Hardt（Hellō）とSam Goto（Google）。IETF Internet-Draft（draft-hardt-email-verification、2026年7月4日提出、個人提案でIETF標準としての正式な地位はまだない）として仕様化され、W3C WICGでもExplainerが公開されている。ChromeとMicrosoft EdgeでOrigin Trialが実施中で、参加メールプロバイダとしてGmailが明記されている。 #protocol #security #browser

解決しようとしている課題

従来の確認メール送信・OTP入力方式は「ユーザーが受信トレイを開いてコードやリンクを取得する」というアウトオブバンドな手順が必要で、次の2つの問題があった。

• ユーザーがサイトを離脱することによるコンバージョン率低下
• 悪意あるサイトによるOTP詐取（フィッシング）への脆弱性

仕組み

1. ユーザーがフォームでメールアドレスを選択する（オートフィル的な体験）
2. ブラウザがメールプロバイダ（issuer）と直接通信し、Email Verification Token (EVT) というJWTを取得する。EVTには検証済みメールアドレスとブラウザの公開鍵が入るが、どのサイト（RP: Relying Party）向けかは含まれない
3. ブラウザ側でKey Binding JWT (KB-JWT)を作り、EVTと結合してRPに提示する（RPのオリジン・nonce等を含む）
4. RPはサーバー側でトークンの署名やDNS由来の発行者情報を検証する

メールプロバイダは.well-known/email-verificationエンドポイントを用意し、トークン発行エンドポイントや署名アルゴリズム（デフォルトEd25519）などのメタデータを公開する。

プライバシー設計

三者モデルの肝は「発行者（メールプロバイダ）がRPの正体を知らない」点。Well-known/Accountsの取得時やトークン発行リクエスト時にRefererやOriginヘッダを意図的に省略する設計になっており、メールプロバイダ側は「ユーザーが今どこかで認証中」だとは分かっても「どのサイトか」は分からないようになっている。RPごとに異なるプライベートなメールアドレスを使い、サイト間相関を防ぐ仕組みも想定されている。

想定用途

アカウント新規作成時のメール確認、パスワードレスサインイン、アカウント復旧フローなど。

FedCMとの関係

同じくブラウザが第三者とRPの間を仲介し、Cookieに頼らず身元・所有権を証明するという設計思想を共有する。FedCMは外部IdPのアカウントによるログイン全般を扱うのに対し、EVPはメールアドレス所有権の検証に特化している。

出典

• Email Verification Protocol - IETF Internet-Draft
• draft-hardt-email-verification-01 - Datatracker
• Email Verification API - WICG Explainer
• Test the Email Verification Protocol with an origin trial - Chrome for Developers

国立情報学研究所（NII）が運営する、大学・短大等の学術機関向け電子証明書発行サービス（certs.nii.ac.jp）。参加は学術機関に限定され、一般企業が代理で申請・利用することはできない。 #security #pki

前身と沿革

2009年4月開始の「UPKIオープンドメイン証明書自動発行・検証プロジェクト」が前身。2015年1月から有料の事業サービスとして現在の形になった。

提供している証明書

• TLSサーバ証明書 — 最大有効期間198日
• クライアント証明書 — 個人だけでなく、役職や部署単位でも発行可能
• タイムスタンプサービス用証明書
• コード署名用証明書 — 新規・更新発行は2023年3月に終了済み

発行数に制限がないのが特徴。

料金・運用体系

参加機関の専任教職員・研究者数に応じた料金体系で、年次更新制（毎年2月末〜3月上旬頃に更新確認）。参加機関側にも、発行・失効した証明書数やドメイン所有権の検証方法などを年次報告する義務がある。2026年4月以降、料金改定が予定されている。

ACMEプロトコル対応(2025年11月〜)

2025年11月12日、ACMEプロトコルに対応した。Certbot等のACMEクライアントを使って、サーバ証明書の発行・更新・失効を自動化できるようになり、運用負荷が軽減された。登録責任者向けの認証情報管理マニュアル、システム管理者向けのACMEクライアント運用マニュアルなど、専用マニュアルが整備されている。

学術機関向けの証明書発行という、Let’s Encrypt的な「無料・自動化されたCA」とは出自の異なるサービスにも、ACME対応という形で自動化の流れが波及している例といえる。

出典

• トップページ | UPKI電子証明書発行サービス
• サービスについて | UPKI電子証明書発行サービス
• 証明書について | UPKI電子証明書発行サービス
• 概要 | UPKI電子証明書発行サービス
• 【重要】UPKI電子証明書発行サービス、ACMEプロトコル対応のお知らせ

OpenAPI Initiative(Linux Foundation傘下)がコミュニティ主導で策定する、複数のAPI呼び出しの並び順と依存関係を「ワークフロー」として記述するための、プログラミング言語非依存の仕様。最新バージョンはArazzo Specification 1.0.0。

何を解決するか

OpenAPI(やAsyncAPI)は個々のエンドポイントの入出力は定義できるが、「あるAPIの呼び出し結果を別のAPIの入力として使う」といった複数API呼び出しをまたぐ順序・依存関係までは表現できない。Arazzoはこのギャップを埋める、OpenAPIを補完するレイヤー。

ドキュメント構造

トップレベルのArazzoオブジェクトが以下を宣言する。

• バージョン・メタデータ
• 参照元となるOpenAPI(やAsyncAPI)の記述ファイルのリスト
• 1つ以上のworkflow(ワークフロー)。各ワークフローは入力(inputs)・順序付きのステップ(steps)・成功条件・後続ステップが参照できる出力(outputs)を持つ
• 再利用可能なコンポーネント

記述例

公式リポジトリのサンプル(petstoreのクーポン適用ワークフロー)から一部抜粋。「ペットを検索する」→「そのペット向けのクーポンを検索する」→「クーポンを適用して注文する」という3ステップのワークフローを表現している。

arazzo: 1.0.0
info:
  title: Petstore - Apply Coupons
  version: 1.0.0
sourceDescriptions:
  - name: pet-coupons
    url: ./pet-coupons.openapi.yaml
    type: openapi
workflows:
  - workflowId: apply-coupon
    summary: Apply a coupon to a pet order.
    steps:
      - stepId: find-pet
        description: Find a pet based on the provided tags.
        operationId: findPetsByTags
        parameters:
          - name: pet_tags
            in: query
            value: $inputs.my_pet_tags
        successCriteria:
          - condition: $statusCode == 200
        outputs:
          my_pet_id: $response.body#/0/id
      - stepId: find-coupons
        description: Find a coupon available for the selected pet.
        operationId: getPetCoupons
        parameters:
          - name: pet_id
            in: path
            value: $steps.find-pet.outputs.my_pet_id
        successCriteria:
          - condition: $statusCode == 200
        outputs:
          my_coupon_code: $response.body#/couponCode
      - stepId: place-order
        description: Place an order for the pet, applying the coupon.
        workflowId: place-order
        parameters:
          - name: pet_id
            value: $steps.find-pet.outputs.my_pet_id
          - name: coupon_code
            value: $steps.find-coupons.outputs.my_coupon_code
        outputs:
          my_order_id: $outputs.workflow_order_id
    outputs:
      apply_coupon_pet_order_id: $steps.place-order.outputs.my_order_id

ポイント:

• sourceDescriptionsで、このワークフローが参照する既存のOpenAPI定義ファイル(pet-coupons.openapi.yaml)を紐付ける。ステップ内のoperationIdはそのOpenAPI定義のoperationIdを指す
• 各ステップはstepIdで識別され、デフォルトでは配列の順番通りに逐次実行される
• $inputs.xxx・$steps.<stepId>.outputs.xxx・$response.body#/...のようなランタイム式(runtime expression)で、ワークフロー入力・前ステップの出力・レスポンスボディの値を後続ステップのparametersに渡せる
• successCriteriaでステップの成功条件(例: $statusCode == 200)を明示できる
• 3つ目のステップplace-orderはoperationIdの代わりにworkflowId: place-orderを指定しており、単一APIオペレーションではなく別のワークフローを呼び出すことでステップの再利用を実現している(この例では同一ファイル内のplace-orderワークフローを参照)

ユースケース

• 対話的な「生きた」APIドキュメント、ドキュメント自動生成
• 機能的なユースケースに基づいたSDK・コード生成
• テストケースの自動化、規制コンプライアンスチェックの自動化
• LLM(AIエージェント)によるAPIの決定論的な呼び出し

Spectralでのサポート

Spectralはspectral:arazzoという組み込みルールセットでArazzo v1.0のlintに対応している。

#openapi #api

出典

• Arazzo Specification – OpenAPI Initiative
• The Arazzo Specification – A Deep Dive - Swagger Blog
• Arazzo Specification (GitHub: OAI/Arazzo-Specification)
• pet-coupons.arazzo.yaml (公式サンプル)

文字列の集合を、根から葉までの経路が1つのキーに対応する木構造で表現するデータ構造。「prefix tree(接頭辞木)」「digital tree」とも呼ばれる。共通の接頭辞を持つキー同士がノードを共有するため、プレフィックス検索(前方一致検索)を効率的に行える。 #algorithm #data-structure

歴史

1959年、René de la Briandaisが論文 “File searching using variable length keys” で最初に導入した。名前は1960年代にEdward Fredkinが独立に考案し、"retrieval"(検索)の中間音節からtrieと名付けた。発音は本来「tree」と同じ/triː/だが、「tree」と区別するために/traɪ/(「try」と同じ)と発音する人も多い。

2000年代、Googleがオートコンプリート機能に採用したことで改めて注目を集めた。

実装上の課題と派生構造

素朴なTrie実装(各ノードが子への配列やハッシュマップを持つ)は、特にアルファベットの種類が多い場合(漢字など)にメモリを浪費しやすい。この課題に対処するため、いくつかの圧縮・高速化手法が考案されている。

• ダブル配列 — TRIEをBASE配列とCHECK配列の2本に圧縮して表現する手法。MeCabなど日本語形態素解析器の辞書引きで広く使われる
• MARISA — パトリシアトライ(Patricia Trie、共通接頭辞を持つ単一子ノードの連鎖をまとめて圧縮したTrie)を再帰的に用いて、さらに高い圧縮率を実現する静的Trie
• Patricia Trie — 単一の子しか持たないノードの連鎖を1つのノードにまとめることでメモリを節約する、Trieの基本的な圧縮手法

出典

• Trie - Wikipedia
• Edward Fredkin - Wikipedia

パトリシアトライを再帰的に用いて表現する、静的(構築後は更新不可)で空間効率の良いTrieデータ構造。開発者はSusumu Yata(s-yata)。C++実装がGitHub上で公開されている。 #algorithm #data-structure #nlp #rust

仕組み

パトリシアトライ(共通接頭辞を持つ単一子ノードの連鎖をまとめて圧縮したTrie)を、さらに別のパトリシアトライで表現するという再帰的な構造を持つ。再帰の深さを増やすほど辞書はより圧縮されるが、検索性能は低下するというトレードオフがある。木のトポロジー自体はLOUDS(Level-Order Unary Degree Sequence)符号化で表現される。

サポートする操作:

• Lookup — 与えられた文字列が辞書に存在するか確認
• Reverse lookup — IDからキーを復元
• Common prefix search — 与えられた文字列の接頭辞に一致するキーを検索
• Predictive search — 与えられた文字列で始まるキーを検索

ダブル配列との違い

どちらも静的なTrie実装で、更新には再構築が必要という点は共通する。

• メモリ効率: MARISAはダブル配列よりもかなりコンパクトになる傾向がある(英語版Wikipediaの記事タイトル約980万件のベンチマークで、他のダブル配列実装が数百MBになるのに対しMARISAは約50MBに収まる例が示されている)
• 検索速度: ダブル配列は兄弟ノード数によらず一定して高速な検索ができる。MARISAも実用上十分高速だが、再帰の深さによっては劣る場合がある
• 日本語辞書のように親ノード1つに対する子ノード数(分岐数)が多くなりがちなケースでは、ダブル配列よりMARISAの方が空間効率の面で有利になりやすい

関連

tokuhirom自身がC++版MARISAをRustに移植したrsmarisaを開発している。C++版とのバイナリ互換性を保ちつつ、LOUDS符号化によるトライ構築・完全一致検索・共通接頭辞検索・予測検索・メモリマップドI/Oなどの主要機能を実装している。

出典

• GitHub - s-yata/marisa-trie
• MARISA: Matching Algorithm with Recursively Implemented StorAge (公式ドキュメント)
• marisa-trie · PyPI

TRIE(トライ木)をBASE配列とCHECK配列という2つの配列に圧縮して表現するデータ構造。青江順一(Jun-ichi Aoe)が1989年にIEEE Transactions on Software Engineering誌に発表した論文 “An Efficient Digital Search Algorithm by Using a Double-Array Structure”(vol.15, no.9, pp.1066-1077)で提案した。 #algorithm #data-structure #nlp

仕組み

元のTRIEでは各ノードがエッジラベル(文字コード)ごとに子ノードを指す行テーブルを持つが、これはスパース(疎)になりがちでメモリを浪費する。ダブル配列はこのスパースな行テーブルを「ずらして重ね合わせる」ことで、単一の配列に圧縮する。

• BASE配列 — 各ノードからの「ずらし量(オフセット)」を記録する
• CHECK配列 — ある位置が本当に期待した親ノードの子であるかを検証する

検索は「現在位置のBASE値 + 次の文字コード」で次の位置を計算し、CHECK配列でその位置の親が正しいか確認する、という手順を繰り返す。この検証があるため、別の親の子ノードを誤って辿ってしまう問題を防げる。1文字あたりの遷移がO(1)で行えるため、キー長kに対して検索全体はO(k)となる。

応用

形態素解析、スペル訂正、日本語かな漢字変換の辞書検索など、高速なプレフィックス検索が必要な場面で広く使われている。実装としてはMeCabの辞書引きや、Darts(Double-ARray Trie System)などが知られる。

出典

• An Efficient Digital Search Algorithm by Using a Double-Array Structure | IEEE
• A fast digital search algorithm using a double‐array structure - Aoe - 1989 | Wiley
• 情報系修士にもわかるダブル配列 - アスペ日記
• Static Double Array Trie (DASTrie)

情報処理学会「文書処理とヒューマンインタフェース研究会」(1987)に掲載された論文「Emacsと親和性の高い日本語入力法 Kanzen」(竹内郁雄・杉村利明・天海良治、NTT電気通信研究所)で発表された日本語入力・かな漢字変換システム。TAO/ELIS(Lispマシン)上のEmacs互換エディタ「Zen」に組み込まれた。 #nlp #emacs

特徴

• Emacs本来のコマンド体系との高い整合性を保つ
• 編集とかな漢字変換が透過的に融合しており、専用の「変換中モード」を持たない。編集コマンドはいつでもどこでも実行できる
• WYSIWYGなリアルタイム画面表示
• モードの区別をカーソル形状(または色)で示し、ユーザの注視点を安定させる

辞書構成

単語辞書はユーザ辞書・基本単語辞書(約7万語)・ディスク単語辞書の3階層で構成される。まず高速なユーザ辞書と基本単語辞書を検索し、候補が見つからない場合のみディスク単語辞書も検索する2段階方式を採る。

変換アルゴリズム

変換対象文字列全体から、単語間の接続関係を表した「解析グラフ」を構築する。各ノードは自分から先頭ノードに至る経路のうち最小コストからm番目までの経路を保持しており、この特性により複数文節にまたがる誤変換(例:「彼ははだし」→「枯葉派だし」)を防ぎつつ、第1文節のみを高速に確定できる。1回の変換・再表示は約100ミリ秒のオーダーで、人間が遅延を感じない限界とされる約50ミリ秒に近いとされる。

辞書のデータ構造について

論文本文では辞書は上記の3階層構成のみが述べられており、辞書引きの内部アルゴリズム(索引構造)についての記述はない。同じくNTTで研究された日本語入力の高速化技術としてダブル配列があるが、ダブル配列の提案(青江順一, 1989年)はKanzenの発表(1987年)より後であり、両者の直接の関連は文献上確認できていない。

出典

• Kanzen: A Japanese Text Input Method Highly Compatible with Emacs

OpenAPI仕様の次期メジャーバージョン(通称OpenAPI 4.0)を探索する特別委員会(SIG)、およびその取り組み全体の通称。2023年12月に開始され、毎週火曜9時(太平洋時間)に定例会を開催している。公式リポジトリOAI/sig-moonwalkでは「4.xを見据えた検討だけでなく3.x側の改善も含めて将来を探る取り組み」と説明されており、終了予定日は定められていない。公式には「4.0には計画された終了日がないため、現時点で存在する3.xバージョンの利用を強く推奨する」と明記されている。

6つの基本原則

当初5つだった原則が、2024〜2025年にかけて6つに拡大した。

1. セマンティクス — 人間・AI双方の利用者に目的(purpose)を提供する
2. シグネチャ — HTTPの仕組みに基づいてAPI操作を識別可能にする
3. 包括性 (Inclusion) — HTTPベースの全APIを記述対象としつつ、特定の実装に偏らない中立性を保つ
4. 基盤インターフェース (Foundational Interfaces、2024年追加) — ツール作成者側の複雑さを削減する。Henry Andrewsの研究により実現可能になったとされる
5. 関心の分離 — スコープをモジュール化し管理可能な単位に保つ
6. 機械的アップグレード — 3.xから4.0への自動変換プロセスを用意する

2025〜2026年の焦点: LLM/AIエージェント対応

2026年は少なくとも最初の半年、OpenAPIとLLMの交差領域に焦点を当てる方針が示されている。LLMを新しいクラスの「賢いクライアント」と捉え、OpenAPI文書をAIエージェントにとって読み取りやすい(“agent-ready"な)ものにする方法が検討テーマになっている。

進め方

2025年3月時点では正式な仕様のドラフト執筆にはまだ入っておらず、GitHub Discussions上でのArchitectural Design Records (ADR) の議論を通じて意思決定を積み重ねている段階。十分な意思決定が蓄積された時点で正式な仕様執筆に移るとされている。参加はSlackチャンネルやGitHub Discussionsを通じて可能。

OpenAPIの中での位置づけ

現行の最新マイナーバージョンであるOpenAPI 3.1・3.2の先にある、次のメジャーバージョンの検討という位置づけ。

#openapi

出典

• GitHub: OAI/sig-moonwalk
• Moonwalk – 2025 update - OpenAPI Initiative
• OpenAPI v4.0 (A.K.A “Project Moonwalk”) - Bump.sh
• Moonwalk 2026 · OAI/sig-moonwalk Discussion #219

2021年2月にリリースされたOpenAPI仕様のマイナーバージョン。中心的な目的はJSON Schemaとの完全互換性の実現で、公式ブログでも「OpenAPIのJSON Schema関連構造とJSON Schema自体のズレは長年、利用者・実装者双方にとっての課題だった」と説明されている。

JSON Schema Draft 2020-12への完全準拠

3.0のSchema ObjectはJSON Schema Draft 5の「サブセット」でしかなく、完全互換ではなかった。3.1ではSchema ObjectがJSON Schema Draft 2020-12ボキャブラリーに100%準拠するようになった。あわせてトップレベルフィールドjsonSchemaDialectが新設され、文書内のSchema Objectが従うデフォルトの$schema値を宣言できるようになった。

semverからの意図的な逸脱

OAS Technical Steering Committee (TSC) は、JSON Schema 2020-12との整合とOpenAPI 3.0からの学びの反映を優先し、破壊的変更を意図的にマイナーバージョン(3.0→3.1)へ含めるという判断を下した。つまり3.1は「マイナーバージョンは後方互換であるべき」というセマンティックバージョニングの慣習から意図的に逸脱している。

主な変更点

• webhooks — トップレベルフィールドとして新設。帯域外(out-of-band)で登録されるWebhookをOpenAPI Object内で正式に記述できるようになった。3.0にはネイティブな手段がなく、callbacksの転用や仕様外での文書化で代替していた
• nullable廃止 — 3.0.3の独自拡張だったnullableキーワードが廃止され、JSON Schema標準のunion型表現に統一された
• $refと兄弟キーワードの共存 — 3.0.3では$refがdescriptionやexampleなど兄弟キーワードと共存できなかったが、JSON Schemaの挙動に合わせてこの制約が撤廃された
• examples(複数形) — OpenAPI独自の単数形exampleキーワードに加え、JSON Schema標準の複数形examplesキーワードが使えるようになった
• 再利用可能なPath Items — Components ObjectにpathItemsが追加され、Path Item Objectをコンポーネントとして再利用できるようになった
• ライセンスのSPDX識別子表記 — APIライセンスをSPDX識別子で表記可能に

採用状況

Atlassian・Microsoft・Googleなど大手が採用。Swagger UI/Editorも3.1をサポートしている。

OpenAPIの中での位置づけ

OpenAPIのバージョン変遷における一段階。次のメジャーバージョンに向けた検討はOpenAPI Moonwalkを参照。

#openapi #json-schema

出典

• OpenAPI Specification 3.1.0 Released - OpenAPI Initiative
• What’s new in OpenAPI 3.1.0? - Beeceptor
• Upgrading from OpenAPI 3.0 to 3.1 - learn.openapis.org
• Swagger Supports OpenAPI 3.1

initramfs内(userlandが起動する前)で初回起動時に1回だけ実行されるプロビジョニングユーティリティ。JSON形式の設定ファイルを読み込み、ディスクのパーティショニング/フォーマット、ファイル書き込み(通常ファイルやsystemdユニット等)、ユーザー作成などをブートプロセスの非常に早い段階で行う。CoreOS系ディストリビューションの初期設定機構。 #linux #infrastructure

cloud-initとの違い・経緯

CoreOSは元々coreos-cloudinit(cloud-initのCoreOS版)を使っていたが、これはOS起動後に動作するため、ディスクパーティションのような根本的な変更がしにくいという限界があった。Ignitionはその後継として開発され、CoreOS内部では約1年運用されたのち正式公開された。

• 実行タイミング — cloud-initは通常のinit処理の一部として起動後に動くため、ディスクパーティションのような変更がしにくい。Ignitionはinitramfs中に動くため、まっさらなディスクからでもPXEブート等でベアメタルのセットアップができる
• 設計方針 — Ignitionは初回起動時に1回だけ実行され、変数展開(variable substitution)のような複雑さを持たない、よりシンプルで予測可能な設計
• 設定フォーマット — cloud-initはYAMLだが、Ignitionは機械可読性を優先しJSONを採用

coreos-cloudinitは非推奨化され、現在は開発が止まっている。

設定の書き方

Ignition設定(JSON)は人間が直接書くには不向きなため、通常はYAMLで書いた設定をJSONへトランスパイルする2段階のワークフローを使う。

• Butane — 汎用のYAML→Ignition設定トランスパイラ
• FCC (Fedora CoreOS Configuration Format) — Fedora CoreOS向けの同種の仕組み

出典

• Ignition | Ignition documentation
• Producing an Ignition Config - Fedora Documentation
• Cloudy Journey: Introducing Ignition
• GitHub - coreos/coreos-cloudinit [DEPRECATED]
• CoreOS ignition support | oVirt

Linuxのファイルシステムツリーをバージョン管理し、アトミックなアップグレード/ロールバックを実現するライブラリ・ツール(libostree)。単体では汎用のバージョン管理・デプロイ基盤であり、RPMなどのパッケージ管理そのものではない。 #linux #infrastructure

仕組み

• コンテンツアドレス型オブジェクトストア — Gitと同じ発想で、個々のファイルをチェックサム(SHA256)で管理し、変更されたファイルのみを差分配信できる。ブランチに相当する「refs」でツリーの世代を追跡する
• ハードリンクによるチェックアウト — Gitと異なり、リポジトリからチェックアウトする際にファイルをコピーせずハードリンクで配置する。そのためチェックアウト後のファイルは変更不可(immutable)として扱う必要がある
• デプロイメント — /ostree/repoにあるリポジトリ内の特定コミット(SHA256ハッシュ)を1つの「デプロイメント」として扱い、ブートローダーのエントリと紐付ける。複数世代のデプロイメントを同一パーティション内に共存させられるので、更新失敗時は直前の正常な世代に即座にロールバック可能
• 電源断や通信切断時にも、更新はコミット単位でアトミックに適用されるためシステムの整合性が壊れにくい

歴史

2011年10月、Red HatのエンジニアColin Waltersが開発開始。GNOME(upower/NetworkManager/gnome-shell等)のOSレベルの変更をホスト環境を壊さずテスト・反復するための仕組みとして着想した。2012年のGUADEC(GNOME Users And Developers European Conference)で公開発表され、GNOME Continuous(GNOMEの継続的ビルド・配信プロジェクト)の文脈で発展。2013年8月に最初の公開リリース(v2013.6)。Waltersはdpkg/rpmなど他のビルドシステムとも共有可能な独立プロジェクトとして意図的に切り出した。

応用例

RPMパッケージ管理とOSTreeを組み合わせたものがrpm-ostreeであり、Fedora CoreOSやFedora Silverblue/Kinoiteなど、Red Hat系のイミュータブルLinuxディストリビューションの中核技術になっている。組込み分野(Toradex TorizonなどYocto/IoTデバイスのOTA更新)でも使われている。

出典

• OSTree Overview | ostreedev/ostree
• OSTree — Wikipedia
• GitHub - ostreedev/ostree
• Deployments | ostreedev/ostree
• ostree v2013.6 released « Colin Walters
• OSTree for Fedora [LWN.net]

Stoplight社が開発するOSSのJSON/YAMLリンター。OpenAPI (v3.1, v3.0, v2.0)、Arazzo v1.0、AsyncAPI v2.xの組み込みサポートを持つ。汎用ルールセットエンジンとして任意のJSON/YAMLに使えるが、OpenAPI/AsyncAPI/JSON Schemaを念頭に設計されている。

仕組み: given / then / severity

ルールは3要素で構成される。

• given — JSONPath Plusでドキュメント内のチェック対象要素を指定
• then — field(対象内のどのフィールドか)・function(assertion内容)・functionOptionsで検証内容を指定
• severity — error / warn / info / off

組み込みルールセットはextends: ["spectral:oas", "spectral:asyncapi", "spectral:arazzo"]のように参照する。.spectral.ymlをリポジトリルートに置いて設定するのが通例。カスタムルールセットは配列にファイルパス・npmパッケージ・CDN URLを追加でextendsできる（例: OWASP APIセキュリティ観点のルールセット@stoplight/spectral-owasp-ruleset）。

CLI

spectral lint myapifile.yaml --ruleset myruleset.yaml

CI/CD

公式GitHub Action stoplightio/spectral-action が提供されており、リポジトリの.spectral.ymlを尊重してPR上でチェックできる。

Stoplightエコシステムとメンテナンス状況

SmartBearが2023年8月にStoplightを買収し、Spectral・Elements・Prismを自社OSSポートフォリオ(Swagger、SoapUI、Pact)に統合した。買収後はSpectralをSwaggerHubに統合する方向で開発が続いている。公式リポジトリstoplightio/spectral自体は買収後も存続・開発継続している。

他リンターとの関係

Redocly CLIも同種のlint機能を持ち、公式に「Spectralからの移行ガイド」を提供している。両者は競合関係にある。

#openapi #linter #devtools

出典

• GitHub: stoplightio/spectral
• Spectral - Stoplight
• Spectral rulesets - GitHub docs
• Spectral OpenAPI Linting Guide 2026 - QASkills
• GitHub: stoplightio/spectral-owasp-ruleset
• GitHub: stoplightio/spectral-action
• SmartBear to Acquire API Company Stoplight - SD Times
• Elevating API Development with Stoplight - SmartBear Blog
• SmartBear Integrates Stoplight’s Spectral, Elements and Prism into SwaggerHub - DevOpsDigest

RESTful APIをHTTP越しに記述するための言語非依存なインターフェース仕様。正式名称は OpenAPI Specification (OAS)。人間にもマシンにも読める形式(YAML/JSON)でエンドポイント・リクエスト/レスポンス形式・認証方式などを定義し、ドキュメント生成・クライアントSDK生成・モックサーバー・リンティングなど様々なツールの入力として使われる。

Swaggerからの経緯

2011年、Wordnikの辞書チームがSwagger Toolkit（Swagger Specification・Swagger UI・Swagger Codegen）を作成した。Swagger 2.0が2014年にリリースされ広く普及。

2015年、SmartBearがSwagger 2.0仕様をLinux Foundation傘下の新設団体「OpenAPI Initiative (OAI)」に寄贈し、2016年1月1日に仕様名が正式に"OpenAPI Specification"へ改称され、新しいGitHubリポジトリへ移動した。OAIにはSmartBear・Google・IBM・Microsoft・PayPal・SAP・Salesforceなどが名を連ねる、ベンダー中立なオープンガバナンス組織。

現在の用語整理としては、「Swagger」はSmartBearが提供するツール群（Swagger UI/Editorなど）を指す通称として残り、「OpenAPI」が仕様そのものを指す。詳しくはSwagger参照。

バージョン変遷

• 2.0 (Swagger, 2014) — OAI移管前の最終形。今も"Swagger"の名で呼ばれることが多い
• 3.0 (2017) — OpenAPI Initiative発足後、最初のメジャーバージョン
• 3.1 (2021) — schemaがJSON Schema Draft 2020-12に完全準拠。webhooks新設など、TSCが意図的にsemverの慣習を破った変更を含む。詳細はOpenAPI 3.1参照
• 3.2.0 (2025年9月) — hierarchical tags、QUERYメソッド、ストリーミングAPIのネイティブサポートを追加

次期メジャーバージョン(通称OpenAPI 4.0)の検討はOpenAPI Moonwalkという取り組みで進行中。

契約ファーストとの関係

gRPCが.protoによる契約ファースト(スキーマを先に定義してからコード生成)なのに対し、REST + OpenAPIはエンドポイントを実装してから後付けでスキーマを書く流れになることが多い。ただしOpenAPI定義を先に書いてopenapi-generatorでスタブコードを生成する契約ファーストな運用も可能。

エコシステム

Spectralによるリンティング、Redocly CLIによるlint/bundle、Swagger UI/Editorによる可視化、openapi-generatorによるコード生成、oasdiffによる破壊的変更検出、Prismによるモックサーバーなど、周辺ツール群はOpenAPI関連ツールエコシステムにまとめた。

#openapi #api #json-schema

出典

• OpenAPI vs Swagger: What’s the Difference? - Postman Blog
• Swagger (software) - Wikipedia)
• What’s new in OpenAPI 3.1.0? - Beeceptor
• OpenAPI Specification - swagger.io
• OpenAPI 3.2 History - Bump.sh

SmartBear提供のOSSツール2本。歴史的にはOpenAPIの前身であるSwagger Toolkit(2011年、Wordnikの辞書チームが作成)の構成要素に由来する。Swaggerブランド全体の位置づけについてはそちらを参照。

• Swagger Editor — OpenAPI/AsyncAPI仕様に基づくHTTPベース・イベント駆動APIの設計・定義・文書化を行うOSSエディタ(ローカル/Web両対応)
• Swagger UI — OpenAPI(Swagger)仕様で定義されたAPIドキュメントを視覚的にレンダリングし、実装ロジックなしにブラウザ上でAPIリソースを可視化・操作できるOSSプロジェクト

同じSmartBearが商用版としてSwaggerHubを提供している。

#openapi #api-documentation

出典

• Swagger Editor - swagger.io
• Swagger UI Getting Started - swagger.io

OpenAPI仕様を中心に育ったツール群を束ねるハブノート。「定義の品質を静的にチェックする」「定義を可視化・文書化する」「定義からコードやモックを生成する」「バージョン間の互換性を見る」という役割ごとに整理する。

各ツール

• Swagger — SmartBearのツール群のブランド名。仕様名としてのOpenAPIとの使い分けを整理
• Spectral — Stoplight製のOSSリンター。JSONPathベースのルールでOpenAPI/AsyncAPI文書の書き方の品質をチェックする
• Redocly CLI — Redocly製のlint/bundle CLI。Spectralと競合するリンター機能を持つ
• Swagger UI / Swagger Editor — SmartBear製、API設計とドキュメント可視化の定番
• openapi-generator — 定義からクライアントSDK・サーバースタブ・ドキュメントを自動生成。swagger-codegenからのfork
• Prism — OpenAPI定義からHTTPモックサーバーを起動。Spectralと同じStoplight系
• oasdiff — 2つの仕様間の破壊的変更を検出。CIでの互換性チェックに使う

Stoplight系とRedocly系

SmartBearが2023年にStoplightを買収したことで、Spectral・Prism・Swagger(UI/Editor/Hub)が同じSmartBear傘下のOSSポートフォリオに集約されている。これに対しRedocly社は独立系で、Spectralの代替となるlint/bundle機能を持つRedocly CLIを提供し、公式に移行ガイドまで用意している。

#openapi #moc #devtools

Redocly社製のOSS CLI。OpenAPI定義に対するlint（設定した基準に沿っているかチェック）とbundle（$refを解決して単一ファイルへ結合し、他ツールへ渡す用途）が代表的なコマンド。

Spectralとは競合するツールで、公式に「Spectralからの移行ガイド」を提供している。Spectralの--ruleset/-rオプションに相当するものとしてRedocly CLIでは--extendsでルールセットを指定する対応表が用意されている。推奨ルールセットはSwagger・Spectral・OAS-Kitからの着想を明記している。

#openapi #linter #devtools

出典

• Lint and bundle - Redocly
• Migrate from Spectral - Redocly
• GitHub: Redocly/redocly-cli

Stoplightが開発するOSS。OpenAPI v2/v3(v3.1含む)やPostman CollectionからHTTPモックサーバーを生成する。

-dフラグでFaker.jsを用いた、スキーマに準拠したランダムなダミーレスポンスを生成できる。単なるモックだけでなく、リクエスト/レスポンスのバリデーションや、実サーバーの手前に立ててレスポンスを検証するValidation Proxyとしても使える。

Spectralと同じStoplightエコシステムの一部で、SmartBearによるStoplight買収(2023年8月)後はSwaggerHubへの統合対象になっている。

#openapi #mocking #devtools

出典

• GitHub: stoplightio/prism
• Prism - Stoplight

OpenAPI/Swagger定義からAPIクライアントライブラリ(SDK)・サーバースタブ・ドキュメント・設定を自動生成するOSS。

swagger-codegenからのfork

OpenAPI Generatorは、swagger-codegenのバージョン2.3.1〜2.4.0の間、2018年5月にコミュニティ主導でforkされたプロジェクト。fork理由として以下が挙げられている。

• swagger-codegen 3.0.0が2系の哲学から乖離しすぎていた
• 2系/3系の並行メンテナンスへの懸念
• より速いリリースサイクル（週次パッチ・月次マイナー）を求めた
• 元のswagger-codegenアーキテクチャは新言語サポートの追加が困難で、Javaベースのテンプレートシステムのカスタマイズも煩雑だった

#openapi #codegen #devtools

出典

• Fork Q&A - OpenAPI Generator公式
• GitHub: OpenAPITools/openapi-generator

2つのOpenAPI仕様間の差分・破壊的変更検出を行うOSSツールチェーン。509種類の変更を検出可能で、breaking/non-breaking双方を区別できる。OpenAPI 3.0/3.1/3.2すべてに対応。

CLI・GitHub Action・オンラインの無料サイドバイサイド比較サービスなど複数の利用形態がある。GitHub Action(oasdiff/oasdiff-action)はPRのFiles changedタブにインラインで破壊的変更を注釈し、fail-on閾値以上ならワークフローを失敗させられる。

使いどころ

API定義の変更がクライアントを壊さないかをCI上で機械的にチェックする用途。OpenAPI関連ツールエコシステムの中では、Spectralが「定義の書き方の品質」を見るのに対し、oasdiffは「2バージョン間の互換性」を見る点で役割が異なる。

#openapi #api #ci-cd

出典

• oasdiff公式
• Using oasdiff to Detect Breaking Changes in APIs - Nordic APIs
• GitHub: oasdiff/oasdiff-action

CoreOS社の Container Linux が2020年5月にEOLとなった際の公式後継ディストリビューション。Fedora Projectのイメージベース・自動アップデートの系譜（Silverblue等と同じrpm-ostree系統）と、Container Linuxの設計思想を統合したもの。 #linux #infrastructure

イミュータブル設計

ルートファイルシステムは読み取り専用でマウントされ、書き込み可能なのは/etcと/varのみ。アプリケーションはコンテナとして動かす前提で、ホストOS自体は手で変更しない（構成ドリフトを防ぐ）という設計になっている。

• rpm-ostree — RPMパッケージ管理とOSTree（Gitのようにファイルシステムツリーをコミット単位でバージョン管理する仕組み）を組み合わせたハイブリッドパッケージシステム。OS全体を1つのイメージとしてアトミックに更新・ロールバックできる
• 更新は新しいOSTreeコミットをステージしておき、次回再起動時に切り替える方式。起動に失敗すると自動的に直前の正常なツリーに戻る
• Ignition — 初回起動時のプロビジョニングを担う仕組み。従来型のインストーラを使わず、JSON形式の設定ファイル（クラウドの場合はユーザーデータ経由で渡す）を初回起動時に読み込んで自己設定する

リリースストリーム

stable / testing / next の3ストリームで段階的に検証しながら配信される（Fedora本体のリリースサイクルとは別に、CoreOS独自のケイデンスで更新される）。

関連

Red Hat OpenShiftのノードOSであるRHCOS (Red Hat CoreOS) は、Fedora CoreOSを上流として派生した製品版。

出典

• Fedora CoreOS: Immutable, Auto-Updating & Secure OS | mkdev
• How to run containerized workloads securely and at scale with Fedora CoreOS | Red Hat Developer
• Immutable Linux Infrastructure Guide (2026 Guide) | FOSS Linux

沖縄県八重瀬町（旧・具志頭村）字長毛の港川遺跡で発見された、後期旧石器時代の化石人骨。日本列島で発見された全身骨格を持つ人骨としては白保竿根田原洞穴遺跡（27,000年前）に次ぐ古さ。

発見の経緯

• 1967年、アマチュア考古学研究家の大山盛保が石灰岩の石切場でイノシシの化石を発掘
• 1968年1月、断片的な人骨を発見
• 1970年8月〜12月、東京大学の鈴木尚らのチームによる本格発掘調査で、4体分（男性1体・女性3体）の全身骨格が出土
• 1998年以降にも追加調査が実施されている

人骨は「フィッシャー（fissure、裂か）」と呼ばれる石灰岩の割れ目の中から出土した。フィッシャーは鍾乳洞の形成過程でできる地質構造で、動物や人間の遺骸が自然に落ち込んで堆積・保存されやすい環境になっていた。

年代

伴出した炭化物・イノシシ遺骨の放射性炭素年代測定により、約1万8000年前〜2万2000年前（後期旧石器時代）のものとされる。

身体的特徴

• 男性は身長約155cm、女性は約144cmと小柄
• 下半身は筋肉質で頑丈な一方、上半身は華奢
• 握力・咀嚼力が強かったことが骨格から読み取れる
• 骨内部には栄養不足による成長阻害の痕跡も見られる

起源説

国立科学博物館などの研究では、港川人の顔立ちはオーストラリア先住民やニューギニアの集団に似ているとされ、東南アジア〜オーストラリアに広く分布していた集団に起源を持つ可能性が指摘されている。

一方、2021年のミトコンドリアDNA解析では、港川人は縄文人の直接の祖先ではなく、共通祖先から東南アジア付近で分岐した別系統の子孫であることが示唆された。

出典

• 港川人 - Wikipedia
• 港川遺跡
• 「港川遺跡」町指定文化財に | 八重瀬町
• 八重瀬町立具志頭(グシカミ)歴史民俗資料館｜1万8千年前の港川人のことがよくわかる | たびらい
• 港川遺跡・港川フィシャー | 沖縄観光情報WEBサイト おきなわ物語
• Minatogawa Man - Wikipedia

#旧石器時代 #沖縄 #人類進化

慶応3年10月14日（1867年11月9日）、徳川慶喜が政権を朝廷に返上した出来事。翌15日に勅許された。

背景

江戸時代を通じて「天皇が統治を将軍に委任している」とする大政委任論が広く受容されていたが、幕末に朝廷が独立した政治勢力として浮上し、幕府権力の正統性が揺らいでいた。薩摩・長州両藩が武力倒幕に傾く中、諸外国の介入を懸念する慶喜は、政権返上によって事態の打開を図った。

土佐藩の建白と後藤象二郎

大政奉還論を推進したのは土佐藩参政・後藤象二郎。薩摩藩の武力倒幕路線に対し、平和的な政体変革を構想した。1867年6月22日、土佐・薩摩両藩の間で「幕府が大政を奉還して権力を一元化し、新たに議事堂を設置して国是を決定すべき」とする薩土盟約が結ばれたが、山内容堂が将軍職廃止条項に反対して建白書から削除し、薩摩側の武力倒幕路線が進んだことで9月に盟約は解消された。なお坂本龍馬が後藤に示したとされる「船中八策」については、後世の創作である可能性も指摘されている。

10月の経緯

• 10月3日 山内容堂が大政奉還建白書を老中経由で慶喜に提出
• 10月13日 二条城に諸藩重臣約50名が集合し、土佐・薩摩・芸州藩らが慶喜に拝謁。大政奉還の意向が公的に表明された
• 10月14日 慶喜が「大政奉還上表」を朝廷に提出
• 10月15日 朝廷が受理・勅許

慶喜による実権維持の狙い

大政奉還の上表には将軍職辞任への言及はなく、慶喜は武家の棟梁としての地位を失っていなかった。10月22日には諸侯会同召集までの条件付きで緊急政務が引き続き幕府に委任され、将軍職も従来通りとされた。10月24日に慶喜は将軍職辞職願を提出したものの、幕府が正式に廃止されるのは同年12月9日の王政復古の大号令まで待たねばならなかった。

その後

大政奉還によって慶喜が構想した公議政体は実現せず、武力倒幕派の薩摩藩・大久保利通や西郷隆盛らは警戒を解かなかった。最終的に王政復古の大号令で幕府は廃止され、慶喜は新政府から排除。翌1868年1月の鳥羽・伏見の戦いへとつながっていく。

出典

• 大政奉還 - Wikipedia
• 大政奉還／徳川慶喜｜ホームメイト
• 大政奉還 | テーマ解説 | 中高生のための幕末・明治の日本の歴史事典

#幕末

「日本資本主義の父」と呼ばれる実業家。1840年（天保11年）、現在の埼玉県深谷市の豪農家に生まれ、1931年（昭和6年）没。

尊皇攘夷から幕臣への転身

幼少期から漢籍を学び、家業の藍玉製造販売で商業的才覚を磨いた。青年期には尊皇攘夷思想に傾倒し、従兄弟らと高崎城乗っ取り・横浜焼き討ちを計画するが中止。その後、一橋家臣・平岡円四郎の推薦で一橋慶喜に仕官し、篤太夫と名乗り士分となった。

パリ万博使節団

1866年に慶喜が将軍となったことで幕臣となった栄一は、翌1867年、将軍名代・徳川昭武に随従してパリ万国博覧会に派遣された。ヨーロッパの産業制度・人間平等主義に触れたこの経験が、後の実業家としての思想の土台になったとされる。渡航中に明治維新が起き、帰国時には仕えていた徳川幕府は消滅していた。

大蔵省官吏から実業界へ

帰国後は静岡藩で商法会議所を設立。1869年に民部省租税正として出仕し、度量衡や国立銀行条例の制定に携わった。1873年、予算編成をめぐる省内対立で大蔵省を辞職し、34歳で実業界に転身した。

第一国立銀行と約500社への関与

大蔵省辞職の1か月後、日本初の民間銀行・第一国立銀行（現・みずほ銀行）の総監役に就任。以後、東京株式取引所、東京瓦斯、東京海上保険、抄紙会社（王子ホールディングス）、45の鉄道会社など、生涯で約500社の設立・経営に関わった。

社会事業と思想

1874年から東京養育院の運営に携わり福祉事業に注力したほか、商法講習所（一橋大学）など教育機関の設立も支援した。著書『論語と算盤』では、経済発展と道徳は両立すべきとする「道徳経済合一説」を提唱している。

徳川慶喜との関係

静岡で謹慎中の慶喜と面会し「これからはお前の道を行きなさい」との言葉を受けたと伝わる。旧主への敬慕は生涯続き、大正7年（1918年）には慶喜の事績をまとめた『徳川慶喜公傳』を刊行した。

出典

• 渋沢栄一 - Wikipedia
• 新紙幣発行記念！ 日本資本主義の父「渋沢栄一」の生涯と功績を徹底解説
• 『青天を衝け』主人公・渋沢栄一の生涯

#幕末

江戸幕府第15代将軍にして最後の将軍。1837年（天保8年）〜1913年（大正2年）、77歳没。

将軍就任まで

水戸藩主・徳川斉昭の七男として江戸小石川に生まれる。母は皇族出身の吉子女王。幼少期に水戸へ移り弘道館で学問・武術を修め、1847年に一橋家を相続。

将軍継嗣問題では斉昭や島津斉彬ら一橋派に推されたが、井伊直弼の大老就任により紀州系の徳川家茂に敗れ、安政の大獄で隠居謹慎処分を受けた。その後、将軍後見職・禁裏御守衛総督として幕政・朝廷折衝にあたり、禁門の変では自ら戦闘に加わった唯一の将軍でもある。

1866年、家茂の死去を受けて将軍職就任を固辞していたが、同年末にようやく受諾。在職中一度も江戸城に入城しなかった唯一の将軍という異色の経歴を持つ。

大政奉還から鳥羽伏見の戦いへ

1867年10月14日、後藤象二郎の建言を受け大政奉還を朝廷に奏上（翌日勅許）。この時点では実質的な政権継続を狙っていたとされる。

しかし同年12月の王政復古の大号令で新政府から排除され、1868年1月の鳥羽・伏見の戦いで敗北。大坂城を脱出して江戸に逃げ帰り、朝敵として追討令を受け官位を剥奪された。

謹慎から晩年

寛永寺・水戸を経て駿府（現・静岡）で謹慎生活を送った後、静岡に28年間居住。狩猟・囲碁・写真・油絵・自転車など多趣味の隠居生活を送り、この間に10男11女をもうけている。

1897年に東京へ移住し、1902年に公爵を授けられ徳川慶喜家を創設、貴族院議員も務めた。

評価

渋沢栄一は大政奉還・江戸城無血開城によって内戦（「第二の関ヶ原」）を回避した功績を高く評価する一方、西郷隆盛は決断力の欠如を指摘するなど、当時から評価が分かれた人物。近年は内戦回避という歴史的功績が再評価される傾向にある。

出典

• 徳川慶喜 - Wikipedia
• 第15代将軍／徳川慶喜の生涯（最後の将軍）
• 第15代最後の将軍／徳川慶喜（よしのぶ）｜ホームメイト

#幕末