Trajectory Design
モデルを賢くする仕事ではない。止める点、固定する点、引き戻す点をアーキテクチャ側に置く。Portable Agent と multi-ai-cli は、この軸のプロダクトである。
長文生成の Drift 測定
正しい事実が先、誤りが後に出る。対処は early stopping に留まる。
01 / MATHEMATICAL PHYSICS × ENGINEERING
確率的揺らぎを、
工学的な確実性へ。
理論と実践を往復する深い探究から導き出した、
展開する技術基盤は2つ。- 生成AI領域では、出力を促すのではなく「軌道」として設計する。
- フロントエンド領域では、流行りのフレームワークにUIライブラリの寿命を依存させない。
UI Core
React や Angular 、Vue の寿命に、UIライブラリの寿命を縛らない。見た目と振る舞いをピュアJSのコアに切り出す。Elem UI は、この軸のプロダクトである。
02 / GENERATIVE AI ARCHITECTURE
AIを「設計問題」として解く
生成AIの出力は本質的に確率的である。最新論文を追うのではなく、「状態空間における軌道のズレ」として定式化し、大規模開発の現場で回る Trajectory Design に落とし込む。中を賢くするな。外を設計しろ。
確率的AIの軌道制御
コンテキスト長 N の増大で初期制約の注意確率 PN は死滅する。続く自己回帰はズレを蓄積する。プロンプトを磨くのではなく、止める点・固定する点・照合する点・引き戻す点をアーキテクチャが担う。
Rollback ≠ Recovery
履歴を巻き戻すことと、正常な制御状態（Control State）へ復帰することは別問題である。局所整合ではなく Artifact の外部固定を優先し、人間ゲートをハブにした復帰条件を設計対象とする。
03 / PARADIGM SHIFT
現象を式に書き、現場に落とす。
意味の Drift、長文の Crowding、Agent の発散、Harness、Plan / Rewind も、先に観測されるふるまいとして扱う。それを設計変数へ写す。ずれは自己回帰の累積として定義する。
Dt+1 = Dt + gt(Dt) + ηt − δt
履歴の巻き戻しと Control State への復帰は別操作とする。Artifact は系の外へ固定し、人間ゲートを復帰条件のハブにする。論文の語彙を機能名へ写すのではなく、現場が操作できる制約へ落とすことが重要である。
t
World
Ashiras
2024.03
Drift を自己回帰の累積として定式化
Dt+1 = Dt + gt(Dt) + ηt − δt。外部介入 δt が無い限り KL は単調増加し、平衡点 D* > 0 へ落ちる。
2025.03
Agent ブーム / Harness 未定着
AutoGPT 型が失速。プロンプト分業が主流。
開発を写像列 Γ として定義
要件→設計→実装を意味複体の変換と見る。人間をハブにした MADD。AI同士の対話協調は捨て、司令塔は人間に固定。
2025.11
Harness Engineering の命名
モデル外側の Runtime が議論の主語になる。
「自浄するマルチエージェント」を棄却
相互監視は観測装置であって閉包の保証ではない。同調バイアスでドリフトは伝播する。Psuccess = (1−δ)n の指数減衰を、会話履歴そのものの設計問題へ翻訳した。
2026.03
セッション分割と 3-agent 体制
Planner / Generator / Evaluator。
成果物固定 + multi-ai-cli
局所整合ではなく Artifact を黒板へ外部化。Agent/Engine を分離し、異種モデルの軌道を HAN 構文（→ と ||）で接続。意味距離ではなく位相保存——制約ID・トレーサビリティ・Persistent Homology——で品質を測る。
2026.06
Plan / Rewind / Worktree の一般化
Harness 機能が各社実装の常識になる。
Trajectory Design
Prompt を初期条件、生成列を軌道、固定点と復帰条件を設計対象にする。Rollback ≠ Recovery。履歴を戻すことと Control State への復帰を分離した。
2026.09
現場適用と承認ゲート
発散制御と人間ゲートが未解決の主問題。
Portable Agent
Work = Goal + Plan + Trajectory + Checkpoint + Control State + Artifact + Guard。状態は Harness が持ち、LLM は交換可能。「仕事を持ち運ぶ。LLMは持ち運ばない。」
04 / FRONT-END ENGINEERING
フレームワークを追うな。コアを置け。
UIパーツが持つのは、見た目と振る舞いである。React や Angular が持つのは、ページを組み立て、状態を持ち、更新を配る層である。層が違うものを、同じ文法の上に置くな。ボタンを React コンポーネントとして書く必要はない。マルチフレームワークの現場では、それが再利用できるかどうかそのものになる。コアは DOM と純関数に置き、枠ごとの書き味だけ薄いラッパーに残す。表舞台に出ることはないが、すでに多くの上場企業の裏側で、この UI Core が静かにシステムを支え続けている。
UIパーツとフレームワークは、層が違う
パーツを枠の寿命に縛った瞬間、Angular の管理画面と React の新規アプリで、同じボタンを二度書くことになる。コアを純関数と DOM 標準に置けば、素の HTML からも同じ振る舞いが出る。CVA も状態転写も皮で足りる。寄せるのは呼び出し側だけだ。マルチフレームワークを採用するほど、依存の向きはこう逆になる。
配色を、感覚ではなく計算にする
デザイナーが画面の上で置いている色の配置を、工学側で出す。メインカラーから補色のアクセント、同系色のベース、背景輝度に対する文字色を計算する。現場で使っているものを公開した。
補色で視線をボタンと通知へ送る。同系色で白背景より階層を出す。輝度から白／黒を自動判定し、無彩色でも同化させない。
05 / COMPANY
COMPANY
現場の複雑性を統括する、全層の実装経験
当社の技術的視座は、代表がエンタープライズ領域で重ねてきたシステム構築の経験に裏打ちされている。かつて Microsoft MVP として評価され、多岐にわたる産業ドメインにおいて、データ層の設計からバックエンド、フロントエンドに至るまで、システムの全層を担ってきた。
決して停止が許されないビジネスの現場で、複雑な要件をシステムに落とし込んできた確かな知見。それがあるからこそ、我々のアーキテクチャは机上の空論に陥らない。現在はこれらの知見をもとに、現場のリアルな制約に即した「開発プロセスの構築」や「アーキテクチャ設計・技術コンサルティング」に注力している。
我々の最大の特徴は、決して外部の傍観者に留まらない点である。設計図を描いて終わるのではなく、自らも当事者として開発の現場に参画する。先進的な理論や究極の技術を、いかにして破綻なく実際のプロジェクトへ実装するか。我々が提供するのは、当事者としての覚悟と、現場主義に基づく具体的な確実性である。
代表の主な開発実績領域
- 製造業向け（生産管理システム、図面系システム）
- 金融・バックオフィス向け（生保系システム、一般会計システム）
- サプライチェーン・物流向け（物流管理システム、在庫連動など）
- CRM・顧客対応（お客様相談センター、顧客管理システム）
一つの思想、二つの基盤
生成AI領域では軌道を置く。フロントエンド領域ではコアを置く。配色は計算する。外を設計し、現場は分ける。
自由度を内側に足しても、軌道は安定しない。モデルを大きくしても、フレームワークを厚くしても、ずれは内側で増える。安定するのは固定点である。生成列なら止める点と復帰条件。UIなら見た目と振る舞いのコア。配色なら補色・同系色・輝度の関係。先にそれを外へ置く。内側は、その上で交換すればよい。
- 会社名
- アシラス株式会社（Ashiras, inc.）
- 設立 / 資本金
- 2016年8月 / 1,000万円
- 所在地
- 〒654-0014 神戸市須磨区若木町4丁目4−3
06 / CONTACT
CONTACT
アーキテクチャ設計や開発プロセスの構築など、現在の課題やご相談内容をご記入ください。