製品ノウハウ

AMU は、SAKU で設計したキャラクターを実際の業務で動かすための製品です。依頼を受け、意図を確認し、道具を選び、下書きを作り、重要な判断は権限レベルに応じて人へ渡します。外部の AI モデルへの接続について、当社は次の方針を取ります。 接続先は利用者が選ぶ 利用者が、自身が契約している外部 AI サービスの API キーを使って接続します。どのサービスを使うか、どのプランで使うかは利用者が選び、設定します。当社が接続先を固定したり、当社経由で中継したりしません。 入力と生成物を当社の学習に使わない AMU に入力した内容と、生成された内容を、当社が AI モデルの学習に使うことはありません。当社が「調整」と呼ぶのはキャラクターの定義ファイルを編集することであり、モデルの学習ではありません。外部 AI サービス側での扱いは、利用者とそのサービスとの契約によります。各サービスの規約を確認してください。 四つの境界 AMU には次の四つの境界があります。 One Voice ── 外に向かって話すのはフロントのキャラクター一人だけ。内部の役割は外

ERABAZU.WORKS は、問い合わせ、案件管理、契約、経費、品質検査、測定データといった業務の道具を、小さな部品から組み立てて提供する仕組みです。すべての道具に共通する設計は、道具が部品として結果を返すだけで、「合格」「不合格」といった判定語を出力しないことです。その結果をどう判断するかは、道具を使う人、またはキャラクターが決めます。すべての結果を人が確認する仕組みではありません。 道具が示せるのは「基準を満たしていない」まで 道具ができるのは、入力を定められた基準に照らし、「この項目は基準を満たしていない」という事実を示すことです。合格か不合格かを決めるのは、道具ではなく、それを使う人かキャラクターです。基準に照らして問題がなくても、現場の事情で不採用にすることはありますし、基準を外れていても人が理由を添えて通すこともあります。その判断を道具に肩代わりさせません。書き込みは第三層で「意図」として提示し、実行するかは人が決めます。 この区別は、当社の信条「判断と実行を分けて作る」に対応しています。 三層の構造 道具は三つの層で作ります。 不

当社が配布する ZIP やマニフェストには SHA-256 を添えています。受け取った側が、ファイルが公式のものと一致しているかを自分で確かめるためです。 配布元は二つ 当社の配布物を置く場所は、次の二つに限ります。 www.wi-t.com github.com/wi-tcom erabazu.works と kokoroamu.com も当社が運営する公式サイトですが、配布物は置きません。上の二つ以外から入手したファイルは、当社が配布したものと同一である保証がありません。SHA-256 が一致すれば中身は同一ですが、一致の確認そのものを、ダウンロードページ（/kokorosaku）と AI Index（/for-ai）に掲載した値と照らして行ってください。配布元が正しいかどうかは公式確認ページ（/official）で確かめられます。 手順 Windows（PowerShell） Get-FileHash -Algorithm SHA256 <ファイル名> macOS / Linux shasum -a 256 <ファイル名> 表示された 64

SAKU のキャラクターは、利用者からは一人に見えます。しかし内部は「1+7」の構造を持っています。一つのフロントと、七つの席です。この構成は Character File の assistant_composition に書かれ、SAKU_UNIFIED_SCHEMA_V1 で型が決まっています。 八つの席 各席の function はスキーマで固定です（seatN.function: const）。 FRONT_CHARACTER（フロント） ── 利用者と直接やり取りする席はここだけ。問いの枠組み、席への振り分け、所見の統合、最終説明、外への応答を担う SPECIALIST_ASSISTANT（分野専門） ── 職種や領域の知識から意見を出す FACT_SOURCE_CHECK_ASSISTANT（事実・出典） ── 主張に根拠があるか、不確実な点はどこかを示す SAFETY_RISK_PRIVACY_ASSISTANT（安全・リスク・プライバシー） ── 危害、境界の逸脱、個人情報の扱いを指摘する USER_VIEWPOINT_ASSIS

KOKOROSAKU の Builder には Validation（適合チェック）があります。この「適合」という語は、日常の「良い・悪い」とは違う意味で使っています。 適合＝仕様との一致 適合チェックが確かめるのは、Character File の記述が SAKU_UNIFIED_SCHEMA_V1 に一致しているかです。七つの必須項目が揃っているか（required）、値が定められた語彙に含まれているか（各 enum）、項目どうしが矛盾していないか。たとえば hard_invariants、human_handoff_conditions、non_goals はそれぞれ 1 件以上が必要で（minItems 1）、席 8 は LOGICAL_HUMAN_ASSISTANT 以外の値を取れません（seat8.function: const）。スキーマに無い項目を足すこともできません（additionalProperties: false）。 キャラクターとして魅力があるか、業務に向いているかは、適合チェックでは分かりません。それは人が読んで判断

KOKOROSAKU では、キャラクターの人格や判断の傾向を、文章の印象ではなく機械が検査できる仕様（Character File）として書きます。その型を定めるのが、schema/adopted/unified-v1/ にある SAKU_UNIFIED_SCHEMA_V1 です。 本体一つと、付属の契約文書 saku-unified-character.v1.schema.json ── Character File 本体の型（schema_id: SAKU_UNIFIED_CHARACTER_SCHEMA_FROZEN_CANDIDATE、schema_version: final-delta-recovery-closure-2026-09-04） character-extension.v1.schema.json ── 名前空間付きの拡張項目（extensions）の型 internal-consistency-semantic-contract.json ── 項目どうしの意味的な整合についての契約 input-integrity-i