TAG ARCHIVE
japanese
16 MARIA OS blog articles tagged japanese, organized as a Bonginkan topic archive for search engines and LLM retrieval.
Judgment OS / Decision Intelligence OS
Core MARIA OS research on turning organizational judgment into executable decision systems.
Agentic Company Architecture
Research on human-agent organizations, delegation boundaries, role topology, and governed autonomy.
Responsibility Gates and AI Governance
Safety, accountability, fail-closed gates, auditability, and human-in-the-loop control for AI agents.
Multi-Agent Mathematics
Formal models for convergence, stability, game theory, graph dynamics, and multi-agent evaluation.
Evidence, RAG, and Knowledge Governance
Evidence bundles, retrieval architecture, Graph RAG, knowledge trust, and auditable reasoning pipelines.
Agentic R&D and Judgment Science
Research operations, simulation labs, judgment science, recursive improvement, and experimental AI governance.
AIで記事を量産しない。代表の思想と導入知見を公開資産に変える編集OS
SEOに弱い原因はAI生成ではなく、一次情報・責任主体・事業接続の欠落である。ボンギンカン/MARIA OSが取るべきブログ編集方針
Googleが見ているのはAI生成かどうかではなく、人の役に立ち、信頼でき、独自性があるかである。ボンギンカンのブログは、検索キーワードに合わせた一般論ではなく、代表の思想、商談知見、導入事例、技術設計を記事化するべきだ。
自治体AI電話を導入して分かった、代表電話業務がAI化できる条件
代表電話のAI化は音声認識ではなく、用件分類・責任境界・有人転送条件・改善ループの設計で決まる
自治体や公共性の高い組織で代表電話をAI化する時、成否を決めるのは自然な会話ではなく、誰が責任を持つ用件なのかを正しく切り分ける設計である。AI電話をFAQではなく業務ハーネスとして捉える。
AIエージェントが業務で失敗する理由は、LLMではなくハーネス不足である
PoCでは動くのに本番化できない原因を、目的・権限・記憶・停止条件・復旧経路・監査証跡の設計から捉える
企業AIエージェントが失敗する主因は、モデル性能だけではない。目的、権限、記憶、品質、停止条件、復旧経路、監査証跡を囲うハーネスがないまま、AIに行動させようとしていることが本質である。
エンタープライズにMARIA OSを導入する方法: AI実装人材、責任設計、統治された自律性
AIを意思決定者にせず、MARIA OSを企業業務へ導入するための実務的な三層モデル
エンタープライズAIは、自動化が責任設計を追い越した瞬間に止まる。本稿では、MARIA OSをL1操作の自律化、L2判断パターンの支援、L3責任アーキテクチャの人間継承という三層モデルで導入する方法を整理する。
運用されるAIガバナンスは技術的優位性になるか：MARIA OSの現実的評価
内部では自動復旧を攻め、外部ではHITLを厚くする。責任契約・fail-closed・回復経路を実装レイヤーで見る
企業AIの次の優位性は、完全自律を主張することではなく、どこで止めるか、どう復旧するか、人間の責任をどう残すかを本番運用で証明することから生まれる。本稿では、ボンギンカンのMARIA OSが持ちうる技術的優位性と、グローバル・日本市場での現実的な位置づけを、過剰な断定を避けて評価する。
動的ハーネス駆動開発により保守されるアプリケーション
Runtime evidenceを収集し、改修計画へ変換し、AI支援プロダクトを安定運用するための汎用モデル
このアプリは動的ハーネス駆動開発により保守されています。Harness結果を運用証跡として扱い、失敗を境界付きの改修計画へ変換し、内部実装の詳細を公開せずに学習を残す方法です。
ハーネス駆動開発：Runtime Evidenceから逆算してAgentic Systemを作る
実装より先にscenario、gate、scorecard、repair boundaryを設計する開発方法論
ハーネス駆動開発では、dynamic harnessをテスト補助ではなく主仕様として扱う。promptやtoolを書く前に、runtime episode、failure taxonomy、scorecard、authority boundaryを定義し、実装を測定可能な振る舞いへ収束させる。
ガバナンス付き自動実装：Dynamic Harnessが研究意図をコードへ変換する仕組み
設計メモから実装計画、パッチ、再現実行、承認ゲート付きマージまで
自動実装が有用になるのは、何がなぜ変わり、どのruntime episodeが改善し、どのauthority boundaryに触れたかを証明できる時だけである。本稿はdynamic harness内部のgoverned auto-implementation loopを定義する。
MARIA Self-Healing Runtime：Agentic Systemの安全な自律改修基盤
Failure Analyzer、Meta-Harness、Envelope、Memory Store、Human Approval Gate、Loop Controlで自己修復を統治する
MARIA Self-Healing Runtimeは、MARIA OS内部の安全第一の改修runtimeである。失敗を検知し、原因を分析し、境界付き改修を計画し、review可能なPRを作り、横断Harnessで再検証し、再発防止をMemory化しながら、高リスク変更の最終責任を人間に戻す。
Dynamic Workflow Agent監視Harness：安全な業務Agentを量産する方法
監視ツール、品質・製造管理Harness、Loop Guard、Agent BlueprintでDynamic Workflow Agentを量産するMARIA OS設計
Dynamic Workflow Agentはpromptの複製で量産してはいけない。MARIA OSでは、すべての業務AgentをBlueprint、Harness Binding Plan、Quality Observatory、Settlement Ledger、Loop Guard、Memory改善経路を持つ製造単位として扱う。
安全性はfan-inに宿る：fail-closedな並列マルチハーネス設計
エージェント基盤で複数のHarnessを並列実行しても安全性を弱めないための5つの実装規律
エージェント基盤では、1つのactionに対してidentity、authority、trust、surface固有のHarnessを同時に走らせたくなる。しかしfail-closedなsystemでは、素朴な並列化が安全性を静かに弱める。この記事では、正規化されたenvelope列に対するfan-in fold、timeoutの制限側変換、DAG依存、budget、snapshotの設計規律を実装レベルで整理する。
自動改修ハーネス：Runtime Failureを安全でReview可能な改善へ変換する
Failure episode、repair proposal、rollback envelope、approval boundaryによるself-healing agentic system
自動改修は自動実装の次段階である。Dynamic harnessはruntime failureを観測し、driftを分類し、repairを下書きし、evidenceをreplayし、rollbackとapproval boundaryを通してpatchをrouteできる。ただしagentが自分自身の憲法を書き換えることは許さない。
動的ハーネスと位相空間制御：virtual-talentからMARIA OSへ
runtime episode、failure taxonomy、dynamic scorecard、repair proposal、controlled self-healingを、Agentic Society Runtimeの位相制御として再定義する
AI Agentの時代における本質的な問いは、モデルがどれほど賢いかではなく、知能がどの位相に入り、どの位相から戻れなくなるかである。本稿は、bonginkan/virtual-talentのProducer AIで進むDynamic Harness実装を踏まえ、MARIA OSにおけるハーネスをRuntime Governance Layer、さらにAgent runtimeの位相空間を制御する層として定義する。runtime episode、failure taxonomy、dynamic scorecard、repair proposal、controlled self-healingを軸に、静的テストから動的制御へ移行する設計原理を整理し、企業OSとAgentic Societyへ拡張する研究課題を示す。
AI OfficeからAgent HR OSへ: Human + AI Organizationを運営する新しいOS
AI Office、AI Office Building、Agent HR OSを、AIツール群ではなくAI社員を運営する一つのスタックとして捉え直す
企業AIは、孤立した補助ツールから管理されたAI労働へ進みつつある。本稿は、AI Officeが仕事場を、AI Office Buildingが組織トポロジーを、Agent HR OSが採用・評価・昇進・統治の人事レイヤーを担うという全体像を整理し、Human + AI Organization の運営スタックとして解説する。
Agent Officeはホワイトカラーをどう置き換えるのか: 実行レイヤー移管、組織再設計、段階的ロードマップ
職種の消滅ではなく、下書き、調整、報告、追跡、一次判断の実行層がAgent Officeへ移る。公開研究をもとに、その順序と変化管理を整理する
Agent Officeが先に置き換えるのは、ホワイトカラーの人材そのものではなく、白領業務の内部にある実行レイヤーです。OpenAI、OECD、ILO、Anthropic、WEF、NISTの示唆をもとに、どのワークフローが先に移り、組織がどう段階的に変わるのかを、日本語で整理した実務向けブログ記事です。
自律型産業ホールディング：資本×物理×倫理の企業統制を統合する意思決定構造化アーキテクチャ
MARIA OSが従来型ホールディングカンパニーを、資本配分・物理オペレーション・倫理コンプライアンスを同時に統治する自己監視型Fail-Closed企業有機体へと変革する方法
従来のホールディングカンパニーは資本を統治する。従来の製造業は機械を統治する。従来のコンプライアンス部門は倫理を統治する。しかし、この三つを同時に統治する組織は存在しない。この分離こそが、財務最適化が物理的安全性や倫理的制約を無視するあらゆる企業惨事の構造的根本原因である。本論文はAutonomous Industrial Holding（自律型産業ホールディング）を紹介する。これはMARIA OS上に構築された意思決定構造化アーキテクチャであり、資本配分・物理世界オペレーション・倫理ガバナンスを単一のFail-Closed有機体に統合する。我々はHolding StateをUniverse状態のCartesian Productとして形式化し、6段階のCapital-Physical Circulation Loopを離散力学系として導出し、Lyapunov安定性を証明する。さらに、初期展開から完全自己監視・自己最適化運用までの5年間の進化シナリオを提示する。