主権
データと処理の所在は、利用者が書いたポリシーが決めます。プラットフォーム側が黙って移動させることはありません。

HP-09 · CONCEPT / 架空案件
Distributed compute / Edge fabric
HELIX GRIDは、地域・クラウド・エッジに散らばる計算資源を、一つの耐障害ネットワークとして束ねる分散コンピューティング基盤です。
> BOOT SEQUENCE 98%
> 042 NODES ONLINE
> LATENCY 11.8MS
01 / Manifesto
電力網が特定の発電所に依存しないように、計算資源も特定のデータセンターや事業者に依存すべきではない——それがHELIX GRIDの出発点です。ノードは世界中の余剰計算資源の持ち寄りで成り立ち、誰か一社が全体を止めることはできません。私たちが作っているのは、単一のデータセンター企業ではなく、参加者が増えるほど耐障害性が上がる「網」そのものです。
データと処理の所在は、利用者が書いたポリシーが決めます。プラットフォーム側が黙って移動させることはありません。
単一拠点・単一事業者への依存を前提にしません。ノード障害は「起きるもの」として設計に織り込んでいます。
どのノードで何が、いつ実行されたか。実行履歴はいつでも参照・再検証できる状態で保存されます。
02 / Live fabric
計算場所を固定せず、負荷・距離・電力に応じて最適なノードへ。この画面の数値は、実際の運用を想定したデモ用のライブテレメトリ表示です。
JP / SG / DE / US
mixed accelerators
milliseconds
verified tasks
03 / Product
コンピュート・ストレージ・スケジューラは、単体でも組み合わせても利用できます。既存のインフラを置き換えずに、負荷が集中する処理だけを段階的に移すことも可能です。

コンテナイメージをそのまま分散ノード群へ配信し、負荷に応じて自動スケールします。CPU/GPU混在構成に対応し、単発のバッチ処理から常時稼働のAPI推論まで同じ仕組みで扱えます。
地理分散オブジェクトストレージ。指定リージョン内で自動的に複数ノードへレプリケーションし、単一ノードの故障ではデータを失いません。
コスト・レイテンシ・データ主権の制約をポリシーとして記述し、条件を満たす最適ノードへ自動配置します。人間が個々のノードを選ぶ必要はありません。
04 / Use cases
業種も規模も異なるワークロードが、同じ分散ネットワークの上で動いています。レンダリング、研究計算、AI推論から金融・気候・配信まで、性質の違う負荷を同じ配置エンジンが扱います(すべて架空の事例・数値です)。
劇場公開アニメを手がけるオーロラピクチャーズ(架空)は、納期直前にレンダリング負荷が集中し、自社GPUファームだけでは捌けず外部レンダーファームへの依存でコストが膨張していました。遊休ノードへ最大1,200並列でジョブを分散し、締切間近のカットを優先キューで処理する構成に切り替え。レンダー時間を平均61%短縮し、GPUリース費用を34%削減しました。
新素材候補の探索を進める5研究機関の共同プロジェクト(架空)は、各拠点のスパコン予約待ちが数日に及び、共同解析のスケジュールが度々止まっていました。候補構造のスクリーニング計算を共有ノード群へ分散し、JP-DEをまたいで空きノードから順に割り当てる構成にしたところ、計算待ち時間が平均72時間から9時間へ短縮しました。
全国展開する小売チェーン(架空)は、店舗の防犯・来店分析用の画像認識推論をクラウド集約していたため、混雑時間帯にレイテンシが悪化し往復コストも膨らんでいました。推論処理を店舗近接のエッジノードへオフロードする構成に変更し、推論レイテンシを38msから11msへ、クラウド往復コストを47%削減しました。
シンガポール拠点の資産運用会社(架空)は、モンテカルロ法によるリスクシミュレーションの夜間バッチが翌朝の市場開始に間に合わないことが続いていました。計算をリージョン内の分散ノードへ並列実行する構成に組み替えたところ、所要時間が6時間から52分へ短縮し、レポート提出の遅延が解消しました。
気候予測アンサンブル計算を扱う研究コンソーシアム(架空)は、単一データセンターでの実行による電力コストと待機時間が課題でした。計算をDE-USのマルチリージョンへ分散し、余剰電力が豊富な時間帯を優先する構成にした結果、電力あたりの計算効率を28%改善し、CO2換算排出量を31%抑制しました。
アジア圏でライブ配信を提供する動画プラットフォーム(架空)は、視聴者の急増時にトランスコード処理が中央拠点に集中し、配信開始までの遅延が視聴離脱につながっていました。処理をJP-SGのエッジノードへ分散する構成に変更し、配信開始までの遅延を平均2.1秒短縮しました。
$ helix deploy vision-v4 ✓ policy verified ✓ 18 nodes selected ✓ encrypted shards sent RUN 8f2c...91a LOAD ███████░░ 72% P95 14.2ms CO₂ -31% target
05 / Workload routing
必要な性能、実行を許可するリージョン、データが越境してよいかをYAMLのポリシーファイルに記述します。既存のジョブ定義に数行加えるだけで適用できます。
処理とデータを暗号化した上で、条件に合う複数ノードへ分割して配信します。単一ノードの処理内容だけでは全体を復元できない構成です。
実行結果と計算履歴はハッシュ連鎖付きで記録され、あとから第三者が再計算して照合できます。改ざんがあれば検証時に不一致として検出されます。
06 / Layer by layer
一つの事業者や地域に依存しない、検証可能な実行レイヤー。ポリシー・配置・証明の3層が、それぞれ独立に検証できる形で積み重なっています。

地域、権限、コスト上限といった制約をコードとして定義する最上位レイヤーです。運用者が個々のノードを意識せずに、境界線だけを宣言できます。
ポリシーで定めた境界の中から、障害や混雑を避けつつ最適なノードへ仕事を配分する実行レイヤーです。配置判断の根拠はログとして残ります。
出力と実行履歴を暗号学的に照合し、指定どおりのノードで指定どおりの処理が行われたことを事後に証明できる状態を保ちます。
07 / SLA & Redundancy
すべてのワークロードは、地理的に離れた複数ノードへ複製された状態で実行されます。ノード障害の検知から切り替えまでは自動化されており、利用者側でのフェイルオーバー実装は不要です。

| プラン | 稼働率保証 | 冗長構成 | 障害通知 |
|---|---|---|---|
| Starter | 99.9% | 同一リージョン内 2ノード | 月次レポート |
| Growth | 99.95% | 2リージョン / 3ノード | 検知後15分以内 |
| Enterprise | 99.99% | 3リージョン以上 / 5ノード | 検知後5分以内・専任窓口 |
稼働率は月間の計測値に基づく目安です。実際の契約条件はプランごとの利用規約に従います(架空の数値です)。
ワークロードの実行状態は数十秒ごとにチェックポイントとして保存され、ノード障害時は直近のチェックポイントから別ノードで再開します。地理的に離れたリージョンへ複製することで、単一の停電や回線障害がネットワーク全体に波及しないようにしています。
08 / Pricing
vCPU・GPU・ストレージの利用量に応じた従量課金です。最低利用料金や初期費用はなく、使った分だけの請求です。以下は税別の目安です(架空の料金体系です)。
無料枠: アカウント登録後は毎月、vCPU 50時間・GPU 2時間・ストレージ10GBまで無料で利用できます(Starter〜Enterprise共通)。無料枠は月初にリセットされ、繰り越しはできません。
| プラン | vCPU時間単価 | GPU時間単価(標準) | ストレージ | 最低利用期間 |
|---|---|---|---|---|
| Starter | ¥3.8 | ¥148 | ¥2.4 / GB・月 | なし |
| Growth | ¥3.2 | ¥121 | ¥1.9 / GB・月 | 1ヶ月 |
| Enterprise | 個別見積 | 個別見積 | 個別見積 | 12ヶ月〜 |
無料枠を超過すると、超過分から自動的にプラン単価での従量課金に切り替わります。ワークロードが停止することはありませんが、Starter/Growthプランで請求上限(コンソールで設定可能)に達した場合は、新規ジョブの受け付けを一時停止しメールで通知します。実行中のジョブは安全に完了まで継続します。
別途、データ転送量・専任サポート・SLA保証水準に応じたオプション費用が発生する場合があります。
GPU時間単価は標準的なミドルレンジアクセラレータを想定した目安です。長時間・大規模な予約利用には別途ボリューム割引を適用できる場合があります。
$ helix login --token $HELIX_TOKEN
$ helix workload submit \
--file job.yaml \
--policy region=jp,cost<=0.5
$ helix workload status 8f2c...91a
STATE RUNNING
NODES 18/18
P95 14.2ms09 / Developers
ワークロードの投入・監視はCLIまたはREST APIから行えます。PythonとGoのSDKも提供しています。ワークロードの状態変化はWebhookで自分のシステムへ通知でき、ポーリングは不要です。
curl -X POST https://api.helix-grid.example/v1/workloads \
-H "Authorization: Bearer $HELIX_TOKEN" \
-d '{"image":"registry/vision-v4","nodes":18,"region":"jp"}'コンソールでAPIトークンを発行し、送信元IPまたはVPCピアリングを許可リストに登録しておく必要があります。デプロイ対象はOCI準拠イメージのみ対応です(独自形式のイメージは事前変換が必要)。
無料枠でのAPI呼び出しは1分あたり60リクエストまで、リクエストボディは8MBが上限です。Go SDKはベータ版のためWebhook再送機能に未対応で、失敗時はCLIでの状態照会が必要です。
10 / Security & Compliance
暗号化、アクセス制御、監査ログ、インシデント対応の4本柱で運用しています。いずれも「あとから説明できる」状態を前提に設計しています。
転送中・保管中ともに暗号化した状態で処理・保存します。ノード間通信は相互TLSで検証します。鍵の管理はノード運営者から独立しています。
ロールベースの権限管理と、全操作の監査ログを90日間保持します。ログは改ざん検知のためのハッシュ連鎖付きで保存されます。
情報セキュリティマネジメント基準に沿った内部監査を年2回実施し、外部レビュアーによる指摘事項は四半期ごとに公開しています(架空の運用体制です)。
重大インシデントは検知から30分以内に一次報告し、事後レポートを72時間以内に提出します。過去の重大インシデントは公開ステータスページで開示しています。
11 / Team
拠点は分散していても、意思決定は驚くほどシンプルにしています。4名それぞれが異なるレイヤーの責任者として、ネットワーク全体を見ています。

Founder / Infrastructure Lead
「電力網とインターネット、両方の分散設計を10年見てきました。中心を持たない仕組みは壊れにくい。」

Head of Scheduler Engineering
「分散システムは障害が起きてからが本番。そこが一番面白い。前職では毎日それを見ていました。」

Security & Compliance Lead
「信頼は、検証できて初めて意味を持つと思っています。」

Developer Relations
「CLIを書く人の気持ちを、一番わかっていたいんです。」
12 / Journal
ネットワークの拡張、機能追加、社内計測の記録です。月に一度を目安に更新しています。
HELIX STORAGEでレプリケーション先として選択できるゾーンを3から5へ拡張しました(標準のレプリカ数は3のままです)。
スケジューラのポリシーDSLをv2に刷新。コスト制約式の記述をより簡潔にしました。
稼働ノードが42拠点に到達。シンガポール・ドイツのエッジロケーションを追加しました。
Enterprise向けにSLA 99.99%プランの提供を開始しました。
開発者向けCLI v3をリリース。ワークロードのドライラン検証機能を追加しました。
電力効率レポートを初公開。平均計算効率28%改善を確認しました(社内計測・架空データ)。
13 / FAQ
導入検討時によくいただく質問をまとめました。掲載のない内容はサンドボックス相談の際にお尋ねください。
バッチ処理、レンダリング、AI推論など、並列に分割しやすい処理に適しています。常時稼働の単一データベースのような、単一障害点を前提とする処理には不向きです。判断に迷う場合はサンドボックスで実際のワークロードを試すことをお勧めしています。
ポリシーで指定したリージョン内のノードにのみ保存・処理されます。指定外のリージョンへ越境することはありません。
OCI準拠イメージであれば、変更なくそのままデプロイできます。
ノード障害を検知すると、あらかじめ選択済みの冗長ノードへ自動的に処理を引き継ぎます。手動操作は不要です。
月末締め翌月払いで、vCPU時間・GPU時間・ストレージ容量に応じた従量課金です(架空の料金目安です)。
Enterpriseプランは24時間365日、Growth/Starterプランは平日9:00〜18:00の対応です。
14 / Company
運営会社の概要です。分散インフラを標榜する企業として、開発拠点自体も一箇所に集約していません(架空の企業情報です)。
15 / Sandbox cluster