シン・Github構想ーーArtifactHubという考え方――AIが「答える」だけでなく「動く」時代へーー９月１４日追記実施
＜２０２６年８月２４日以前のコンテンツ一覧はこちら＞
＜Claudeの画面に「アーティファクト」というのがありました。深掘りしていくとこれはgithubの拡張に繋がるのではと思いAIに考察してもらいました。そして提案書も作成してもらいました。しかし、頼んでもいないのに「英語版」もどうですか、とは。営業がうまいですねAIは。
９月１４日に追記実施しました。もう少し大きな概念でとらえようということらしいです。＞
＜要約＞
AIの進化というと、これまでは「どれだけ賢く答えられるか」「どれだけ上手にコードを書けるか」が中心でした。ところが今、AIは文章やプログラムを作るだけでなく、企業の業務を進め、複数のAIが役割分担し、さらにはロボットや自動運転、工場設備などを通して現実世界へ働きかける段階へ入りつつあります。
そこで重要になるのが、「AIが何を出力したか」だけではなく、「なぜその仕事を行い、誰の権限で、何を根拠に判断し、実際に何が起きたのか」を後から確認できる仕組みです。
この議論から考えているのが、仮にArtifactHubと呼んでいる仕組みです。
ここでいうArtifactは、単なるファイルではありません。文章、コード、データ、AIモデル、指示、計画、判断、承認、実行記録、失敗記録、証拠など、人間・AI・機械が仕事を進めるために残す「意味を持った情報のまとまり」です。ロボットそのものはArtifactではありませんが、そのロボットの能力、現在状態、移動計画、実行命令、作業結果などはArtifactとして管理できます。
コード中心から「仕事の意味」中心へ
AIによるコード生成が当たり前になると、コードだけを企業資産の中心と考えることは難しくなります。むしろ長く残す価値が高いのは、「何を実現したかったのか」「どんな制約があったのか」「なぜその方法を選んだのか」「誰が承認したのか」といった仕事の意味です。
将来は、Intent（目的）→ Constraint（制約）→ Plan（計画）→ Execution（実行）→ Evidence（証拠）→ Acceptance（受入れ）という流れそのものを保存することが重要になるでしょう。
AIエージェントは無限に考え続けない
AIエージェントが企業で働くとき、万能AIが何でも引き受けるより、役割を限定した複数のAIがArtifactを介して仕事を受け渡す方が管理しやすくなります。
ただし「有限」とは、監視や繰り返し処理を禁止する意味ではありません。Success、Failed、Timeout、Cancelledなど、一回の仕事には区切りを付けます。一方で、WatchやWaitのような継続監視は、内部で考え続けるのではなく、外部イベントを待つ状態として保存します。新しい出来事が起きれば、新しい仕事として再開します。
AIに自由を与えるためにGateが必要になる
AIを安全に使うために、何でも人間が確認していては業務が止まります。そこで、通常は自動的に進め、金額、権限、安全、責任範囲など重要な条件が変わった場合だけ人間へ戻す設計が必要になります。
この考え方では、HGL（Human Guarantee Ledger）が意味、権限、証拠、承認の関係を記録し、Guarantee Gateが外部へ影響を与える直前にAllow、Deny、Ask、Stopを強制します。
Physical AIでは「元に戻す」だけでは足りない
ソフトウェアなら以前のVersionへ戻せる場合があります。しかし、メールを送る、決済する、ロボットが物を動かす、材料を切断するといった行為は、完全には元へ戻せません。
そのためPhysical AIではRollbackだけでなく、Compensation（補償・回復）という考え方が重要になります。失敗したら、影響を広げず、回復できるなら回復し、難しければ事前に定めたSafe Stateへ移行します。さらに補償そのものが失敗しても、補償の補償を無限に続けるのではなく、Containment、Safe State、Human Escalationなどで一度処理を閉じます。
目指すのは「完璧なAI」ではなく「回復できる社会」
最終的に目指したいのは、AIが絶対に間違えない社会ではありません。人間もAIも機械も間違えることを前提に、それでも「何が起きたのか」が分かり、影響を限定し、必要なら修正し、その判断と責任の履歴を残せる社会です。
ArtifactHubは、そのための巨大なファイル置き場ではありません。
Human Intent → Artifact → Intelligence → Assured Action → Evidence → Updated World
という仕事の流れを、人間・AI・Physical Systemの間でつなぐ「仕事の記録基盤」です。
今後、AIの価値は「何を生成したか」だけではなく、「どの意味、どの権限、どの証拠にもとづいて、世界をどう変えたのか」まで含めて評価されるようになるでしょう。ArtifactHubという構想は、その未来に向けて、GitHubの次に何を管理すべきかを考える一つの試みです。
＜現時点をまとめ＞
＜未来を予測＞
＜収集情報＞
＜提案資料概要＞
＜提案資料パワポ形式＞
＜提案資料１枚形式＞
＜２０２６年９月１４日追記＞
2026年9月追記――CodeからComputing Artifactへ
ArtifactHubについて考え始めたとき、中心にあった問いは比較的単純でした。
AIが大量のコード、文章、データ、判断、実行記録を生成する時代に、GitHubのように「コード」を中心として仕事を管理し続けるだけで十分なのだろうか。
そこで、コードより一段上にArtifactという単位を置きました。
Artifactとは単なるファイルではありません。何を実現しようとしたのかというIntent、守るべきConstraint、実装、判断、実行、検証、Evidenceまでを一つのまとまりとして扱うものです。
その後、この考えをAI、AIエージェント、GPU、NPU、FPGA、そして三値AIアクセラレータまで広げて考えていくうちに、Artifactにはさらに一つ重要な種類があることが見えてきました。
ここではそれを、Computing Artifactと呼びます。
CodeはArtifactの一部分になる
従来の開発では、CPUで動かすのか、GPUへ処理を渡すのか、CUDAを使うのか、FPGAを使うのか、といった判断を人間の開発者が行ってきました。そして、その判断に合わせてコードを書きます。
つまり、Hardware / Runtimeを選ぶ → Codeを書く、という順序でした。
Computing Artifactでは、この順序を逆に考えます。
まず、何を計算したいのか。どの程度の精度が必要なのか。どの程度の遅延を許容するのか。消費電力にはどのような制約があるのか。どの数値表現を使えるのか。再現性は必要なのか。どのような検証を通過しなければならないのか。という仕事の意味と制約をArtifact側に持たせます。
そのうえで、Artifact → Compute Placement → Execution Targetと実行先を決める。
CPU、GPU、NPU、FPGAなどは、Artifactを実現するためのExecution Targetになります。
ここでは、ハードウェアが主役ではありません。
Artifactが主で、演算器が従になる。
これがComputing Artifactという考え方です。
46年前の8087に、すでに原型があった
この考え方は、突然2026年に現れたものでもありません。
1980年に登場したIntel 8087は、8086や8088と組み合わせて使う数値演算コプロセッサでした。
8086にはESC命令が用意され、特定の数値演算を8087へ渡し、必要な地点ではWAITによって同期する構造が存在していました。
現在の言葉に置き換えれば、Host CPUが仕事全体を統括し、適切な演算を専用Execution Targetへdispatchする、という構造です。
つまり、Compute Placementという考え方そのものは、少なくとも40年以上前からハードウェアとして存在していました。
その後もDSP、GPU、FPGA、TPU、NPUと、コンピュータは仕事を専門演算器へ渡す方向へ発展してきました。
変わろうとしているのは、その「どこへ渡すか」を誰が決めるのかです。
人間が演算器を選ぶ時代から、Artifactが選ぶ時代へ
現在でも、実行先の抽象化は部分的に始まっています。
ONNX RuntimeではExecution Providerによって異なる演算装置へ処理を配置できます。
Apache TVMではBYOCによって一部の処理を外部backendへ渡せます。
OpenXLAのPJRTでは、フレームワークからデバイス固有実装を切り離す方向が取られています。
MLIRでは複数のdialectやtargetへの変換を扱えます。
これらは、それぞれ別の目的で作られた仕組みです。
しかし一段上から見ると、共通する方向があります。
プログラムの意味と構造を保持したまま、具体的な実行装置を後から選択する。
Computing Artifactは、この流れをさらに上位からまとめようとするものです。
Artifactには、計算条件まで保存される
Computing Artifactには、従来のArtifact情報に加えて、例えば次のような情報が必要になるでしょう。
Precision。Numeric Representation。Memory Budget。Latency Budget。Energy Budget。Compiler / IR。Allowed Backend。Compute Placement。Execution Target。実行前に必要なGuarantee。Execution Evidence。
こうした情報を持てば、AIエージェントは複数の実装候補を比較できます。
例えば、高精度の大規模行列演算ならGPU。小型で常時動作させる推論ならNPU。制御やI/Oが中心ならCPU。特定の固定演算ならFPGA。というように、仕事の意味から実行先を選択できます。
重要なのは、「GPUが速いからGPUを使う」という単純な発想ではありません。
そのArtifactの条件を満たす演算器を選ぶ。
という考え方です。
SETUN-87は、この原理を試すストレステストである
この考え方を確認するために、一つの思考実験を行いました。
1958年に開発された三値コンピュータSetunと、1980年の8087コプロセッサを組み合わせ、三値演算が有利な仕事だけを受け取るAIコプロセッサを仮に「SETUN-87」と呼びます。
SETUN-87という製品が存在するわけではありません。
重要なのは、この名前ではありません。
仮に将来、{-1, 0, +1}の三値重みや低ビット演算に特化した新しい演算器が登場したとしても、Computing Artifactの側にPrecision、Numeric Representation、実行条件、検証条件が記録されていれば、新しいExecution Targetを一つ追加する、という形で扱えるのではないか。
SETUN-87は、その拡張性を試すためのストレステストです。
もしこの考え方がSETUN-87のような未知の演算器にも適用できるなら、Computing Artifactは現在存在するGPUやNPUだけに依存した概念ではありません。
GuaranteeもArtifactの一部になる
実行先を自動的に選ぶようになると、もう一つ必要になるものがあります。
Guaranteeです。
ある処理をGPUへ送ってよいのか。三値化によって必要精度が失われないか。指定メモリ内に収まるか。そのbackendが必要なoperatorを実装しているか。実行結果は要求された条件を満たしたか。
こうした条件を、境界を越えるたびに確認する必要があります。
AI開発が高速化したことで、これまで人間主体では維持コストが高かった大量のcontract、型、validator、test、境界検証を継続的に生成・更新できる可能性が出てきました。
すると、開発の中心は、大量のCodeを生成することから、Guarantee付きArtifactを生成することへ移ります。
GuaranteeそのものもAIが自由に書き換えられるようでは意味がありません。
そこで、承認済みGuarantee集合を署名付きで固定し、境界検証に失敗したArtifactはdispatchしない。さらに、どのGuarantee集合を使用したかをdigestとしてExecution Evidenceへ残す。
このようにすれば、何を実行したか、だけでなく、どの条件を満たしたから実行されたのか、までArtifactHubへ戻すことができます。
Build ProvenanceからExecution Provenanceへ
これまでソフトウェア供給網では、どのソースから、どの環境で、どの成果物が作られたかというBuild Provenanceが重要でした。
Computing Artifactでは、さらにExecution Provenanceが必要になります。
例えば、どのArtifactを実行したか。どのGuarantee Setを使用したか。どのcompiler / IRを通ったか。どのbackendが選ばれたか。どのCPU、GPU、NPU、FPGAで実行されたか。fallbackは発生したか。結果は何だったか。検証は通過したか。といった情報です。
ArtifactHubが「仕事の記録基盤」になるのであれば、このExecution Provenanceも、その重要な構成要素になります。
GitHubがCode Graphなら、ArtifactHubはWork Graphになる
ここまで来ると、GitHubとArtifactHubの違いも、よりはっきりします。
GitHubは長い間、Codeを中心とする巨大なGraphを作ってきました。
repositoryがあり、commitがあり、branchがあり、pull requestがある。
ArtifactHubが目指すものは、それより一段上です。
Intent。Constraint。Artifact。Decision。Execution。Evidence。Acceptance。
それらをつないだWork Graphです。
そしてComputing Artifactは、そのWork Graphから下方向へ、Execution Graphを伸ばします。
関係を簡単に書けば、Human Intent → ArtifactHub / Work Graph → Computing Artifact → IR / Runtime → Compute Placement → CPU / GPU / NPU / FPGA / 新しいExecution Target → Execution Evidence → ArtifactHub、となります。
実行して終わるのではありません。
結果と証拠が、再びArtifactへ戻ります。
CodeからArtifactへ、ArtifactからComputing Systemへ
AIによる開発の変化は、三段階に整理できるように思います。
第1段階は、AI writes Codeです。AIが人間より速くコードを書く。
第2段階は、AI produces Artifactです。コードだけでなく、意味、制約、型、テスト、判断、Evidenceまで含むArtifactを作る。
そして第3段階が、AI composes Computing Systemです。Artifactの意味と制約を読み、CPU、GPU、NPU、FPGA、将来の新しい演算器まで含めて、必要な計算システムを構成する。
ここまで進むと、プログラミングという言葉だけでは少し狭くなります。
AIが作るものはCodeではありません。
意味とGuaranteeを持ち、適切な計算資源へ配置され、その実行結果まで証拠として戻ってくるComputing Artifactです。
Artifactという器は、思っていたより大きかった
ArtifactHubを考え始めたとき、GitHubの次に管理すべきものは何か、という問いから出発しました。
その時点では、Artifactをコードより広い「仕事の成果物」として考えていました。
しかし、その後の議論を通じて、Artifactはさらに深いところまで伸びることが分かってきました。
ソフトウェア。モデル。compiler。IR。runtime。CPU。GPU。NPU。FPGA。そして、まだ存在しない新しい演算器。
それらを個別に主役として考えるのではなく、一つの仕事を成立させるために選択される実行手段として扱う。
その中心に置かれるものがComputing Artifactです。
ArtifactHubの考え方を作り直す必要が出てきたのではありません。
むしろ逆でした。
最初に置いたArtifactという器が、想像していたよりずっと大きかった。
2026年9月時点では、そのように考えています。
