難しい問題を、分けて作る。
大きな問題を役割ごとに分け、どこまでを誰が担当するかを決めてから実装します。
SHUSHULAB / RESEARCH & ENGINEERING
研究から、実際に動くものまで。
ShushuLabでは、AIに開発作業を任せるための仕組み、実際に使うWebサービス、AIエージェントの基盤、音声ソフトウェアを設計・開発・運用しています。分野は違っても、「誰が何を担当するか」「壊れたらどう戻すか」「本当に動いたかをどう確かめるか」を共通して重視しています。
初めて見る方は、下の「4つの領域」だけで全体像が分かります。専門用語を含む設計詳細は、必要な方だけ開いて読めます。
まずこれだけ
何をしているのか。
研究だけ、プログラムだけ、運用だけに分けず、問題を整理するところから実際に使える状態まで一つの流れで扱っています。
作って終わりにしない。
Webサービスなら本番運用、開発基盤なら障害からの回復、音声ソフトなら実際の制作工程まで扱います。
「良さそう」ではなく確かめる。
テスト、Windows / Linux CI、実運用、研究上の検証など、後から確認できる証拠を残して判断します。
4つの領域
分野は違っても、やっていることはつながっています。
まずは専門用語を抜きにして、何を作っているのかだけ見てください。
01 / RELIABILITY
AIに長い開発作業を任せても、壊れたら安全に止めて戻せるようにする。
開発を続けるAIを監視し、失敗の種類を見分け、途中状態を保存し、安全な場所から再開するための基盤です。
Autonomous Development Infrastructure 02 / PRODUCTION仕事の記録、契約、請求、課金を一つのWebサービスで扱う。
ShushuLab自身の運用基盤として、作業記録から契約・署名・請求・決済までをつないでいます。
ShushuLab Production Platform 03 / AGENT RUNTIMEAIの「同じ主体が続いている」を、使うAIモデル任せにしない。
モデルが変わっても、履歴・責任・行動のつながりを別のRuntimeで管理するAgent Architectureです。
Kizuna Engine / POE 04 / AUDIO SOFTWARE歌・録音・編集で繰り返す面倒や不安定さを、役割ごとのソフトウェアにする。
編集自動化、入力を整える処理、声のキャラクター作りを、それぞれ別の製品責務として設計しています。
Vocal Prep / Formant Preamp / Vahlune実物・証拠
説明だけではなく、動いているものがあります。
初見でも確認しやすい実装・運用・研究・製品の証拠をまとめています。
本番で使うWeb基盤
Work Log、Workspace権限、契約・オンライン署名、請求・返金、Stripe、メール、PDFなどを実際のShushuLabサービスとして運用しています。
Work Logを見る →Windows / Linuxで継続検証
変更したcommitを特定し、WindowsとLinuxのCIで確認してから本番反映へ進む運用を組んでいます。障害時の回復や再実行も別の責務として扱います。
POE / Kizuna Engine — 実装を触る
AIの主体・履歴・責任をRuntime側で扱う実装です。クリックすると、実際に動く「夜伽の箱庭」を開きます。論文はAAMAS 2027 Submission #1817としてSubmittedです。
実際のAudio Software製品
Vocal Prep、Formant Preamp、VahluneなどをWindows VST3として開発・検証し、ShushuLabの製品導線へ接続しています。
Audio製品を見る →もう少し詳しく
必要な方だけ、設計の中まで。
ここから下は技術者・研究者向けの深掘りです。各領域の最初に普通の言葉で要点を置き、その下の「技術詳細を見る」を開くと設計判断まで読めます。
01 / AUTONOMOUS DEVELOPMENT
Autonomous Development Infrastructure
AIが長時間開発を続けると、途中で止まる・同じ失敗を繰り返す・状態が分からなくなる、といった問題が起きます。それを前提に、監視と回復を含めて設計した開発基盤です。
何を作った？
実行役、監視役、途中保存、回復処理、失敗の分類、再試行の上限、CI確認を分けた自律開発基盤です。
なぜ必要？
自動化を強くするほど、止める条件・再開する条件・本番へ進めてよい条件を明確にしないと、失敗を高速で繰り返してしまうためです。
何で確かめる？
ShushuLabなどの開発ラインで継続利用し、commit単位のCI確認、クラッシュ後の回復、進捗停止の検知を運用しています。
技術詳細を見る
- 困っていたこと
- 長時間の自律開発では、プロセスクラッシュ、認証・quota・provider障害、同一失敗の反復、no-progress、dirty/divergent state、CI未確定のままの反映が安全性を崩します。
- どう組んだか
- worker / watchdog / checkpoint / recovery / circuit breaker、failure classification、bounded retry / cooldown、repeated-failure / no-progress detection、exact-SHA CI verification、Windows / Linux self-hosted runner、Linux / systemd、deployment / rollback分離を組み合わせています。
- どこで壊れるか
- クラッシュ後の不確実なsession、進捗のない反復、provider障害、branch divergence、dirty working tree、CI対象SHAとデプロイ対象SHAのずれを明示的な失敗として扱います。
- 何を決めたか
- 状態が曖昧なときはfail closed。worker実行、CI判定、本番反映の権限を分離し、checkpointとfingerprintで再開可能性を確認してから処理を続けます。
- どう確かめたか
- ShushuLabを含む複数の開発ラインで、この基盤を用いて修正・テスト・exact-head CI・回復処理を継続運用しています。
- 何ができたか
- 自律性を高めても、障害時に責任主体と再開条件を失わない開発運用を構成しました。
研究状態: working paper / manuscript in preparation。採択済み・出版済みとは表記していません。
02 / PRODUCTION PLATFORM
ShushuLab Production Platform
ShushuLabは紹介サイトだけではなく、仕事の記録、契約、請求、決済、製品運用までを実際に扱うWebプラットフォームです。
何を作った？
Java 21 / Spring Bootで、Workspace、Order、Quote、Contract、オンライン署名、Work Log、Billing / Refund、Stripe、メール、PDFをつないだ本番システムです。
なぜ必要？
お金・契約・顧客データが絡むため、「見える人」「変更できる人」「公開URLでできること」を曖昧にできないためです。
何で確かめる？
実際のShushuLabサービスとしてUbuntu VPS / systemd / HTTPS / Cloudflare上で運用し、権限・課金・Webhook・公開tokenを回帰テストしています。
技術詳細を見る
- 困っていたこと
- 案件、作業記録、見積、契約、署名、請求、返金、製品課金を別々に扱うと、権限・状態・証拠が分断されます。
- どう組んだか
- Java 21 / Spring Boot / Spring Securityを中心に、Workspace role、Order / Quote / Contract / e-signature / Work Log / Billing / Refund、PDF、Resend、Stripe Checkout / Subscription / Webhookを接続しています。
- どこで壊れるか
- Workspace越境、VIEWER/GUEST権限逸脱、public tokenの管理権限化、webhook重複、課金状態の誤推定、CI確認済みSHAと本番反映SHAの不一致を主要な境界として扱います。
- 何を決めたか
- 認証・認可・Product Association・Subscription / Entitlementを分離し、公開文書はtoken境界、本番はUbuntu VPS / systemd / HTTPS / Cloudflare、変更はCI/CDとrollback可能なデプロイ経路で管理します。
- どう確かめたか
- 現在のShushuLabリポジトリと公開サービスに、Workspace、契約署名、Work Log、請求、Stripe、メール、PDF、CI/CDの実装と回帰テストがあります。
- 何ができたか
- 業務データと商用フローを、Workspace境界を維持した一つの運用基盤へ接続しました。
03 / AGENT RUNTIME ARCHITECTURE
Kizuna Engine / POE
Kizuna Engine / POEは、「AIモデルそのものが主体」と決めず、モデルが変わっても続く履歴・責任・行動のつながりをRuntime側で管理する研究と実装です。見出しから、実際に動く「夜伽の箱庭」を開けます。
何を作った？
World、Subject、Runtime、Capabilityを分け、AIモデルを交換可能なCapabilityとして扱うJava 21のAgent Runtimeです。
なぜ必要？
モデルを交換したり、記憶を複製したり、クラッシュから復旧したときに、「同じ主体なのか」「前の行動の責任はどこに残るのか」を明示する必要があるためです。
何で確かめる？
Java 21の実装を設計のconstructive witnessとして使い、論文「Externalizing the Subject: Lineage, Responsibility, and Evidence Across Agent Lifecycle Changes」をAAMAS 2027へSubmission #1817としてSubmittedしています。
技術詳細を見る
- 困っていたこと
- model replacement、context断絶、同一modelの共有、memory複製、clone / fork、クラッシュ後の未解決effectがあると、主体の継続条件と責任の所在が曖昧になります。
- どう組んだか
- World → Subject → Engine → Runtime → Capability の依存方向を分離し、Presence、Action authority、lineage、checkpoint / recovery、managed effectsをRuntime側の責務として扱います。
- どこで壊れるか
- 複数canonical head、memoryコピーを同一主体と誤認すること、未解決actionの二重実行、model変更を主体変更と混同することを設計上の失敗として扱います。
- 何を決めたか
- 主体継続性をLLMから外在化し、single-head lineage、明示的なRecover / Clone / Fork、Actionのauthorizationとattribution、回復時の未解決effect reconciliationを採用します。
- どう確かめたか
- Java 21の実装をconstructive witnessとして、Subject / Runtime / Capability分離、lineage、recovery、managed-effect境界を検証しています。
- 何ができたか
- model非依存の主体継続条件を、履歴・責任・effect境界を持つRuntime過程として明示しました。
PaperExternalizing the Subject: Lineage, Responsibility, and Evidence Across Agent Lifecycle Changes
AAMAS 2027 Submission #1817 / Submitted。これは採択・出版を意味しません。
04 / AUDIO SOFTWARE & R&D
Audio Engineering
Audio Engineeringでは、歌や録音の制作現場で起きる問題を、そのまま「音を良くする一台」に押し込まず、編集・入力整理・キャラクター形成など役割ごとのソフトウェアへ分けています。
何を作った？
C++20 / JUCE 8 / CMake / Visual Studio / Windows VST3で、Vocal Prep、Formant Preamp、Vahluneなどを開発しています。
なぜ必要？
編集の自動化、入力を安定させる処理、音色を作る処理は目的が違うため、一つに混ぜると何が効いたのか、どこが責任を持つのか分かりにくくなるためです。
何で確かめる？
開発用・検証用・最終確認用の証拠を分け、機械計測と人のリスニングを別の確認として扱いながら、製品build / test / productizationへつないでいます。
技術詳細を見る
- 困っていたこと
- 編集反復、入力差、前段処理の不安定さ、音色形成の責務混在を一つの万能処理で解こうとすると、評価も制御authorityも曖昧になります。
- どう組んだか
- C++20 / JUCE 8 / CMake / Visual Studio / Windows VST3。Vocal Prepは編集自動化、Formant Preampはfront-end standardization、Vahluneはharmonics / tone / characterに責務を分離します。
- どこで壊れるか
- 局所指標だけの改善、開発データへの過適合、standardizationとcharacterのauthority競合、DAW上の実用性とmachine measurementの不一致を評価上の失敗として扱います。
- 何を決めたか
- Development / Validation / Held-outを分け、baseline、hypothesis、deterministic fixture、predeclared acceptance rule、negative-result preservationとhuman listening gateを併用します。
- どう確かめたか
- Vocal Prep、Formant Preamp、Vahluneを既存の商品・検証経路で開発し、build / test / productizationをWindows VST3として運用しています。
- 何ができたか
- 編集自動化、入力標準化、キャラクター形成を別責務として扱う製品チェインを構成しました。
KNOWLEDGE / METHODS
設計判断の背景も公開する。
Knowledgeでは、観測、判断、制御、音響など、実装や制作の背景にある方法論を公開しています。