アーパボー(ARPABLE)
アープらしいエンジニア、それを称賛する言葉・・・アーパボー
ALT2026

【1-070426】AIロボット制作プロジェクト 正式キックオフ:Sim2Realで自律制御ロボットを作る・学ぶ・育てる

最終更新:
※本記事はプロジェクトの進行に合わせて継続アップデートされます。

【1-070426】AIロボット制作プロジェクト 正式キックオフ:Sim2Realで自律制御ロボットを作る・学ぶ・育てる


Sim2Realの実装は、もはや大企業の研究所だけの話ではない。
しかし現実には、Physical AIの開発手法・設計パターンを実際に手を動かして体験できるエンジニアは、国内でもごく限られている。
株式会社アープは2026年4月7日、この現実を変えるためのプロジェクトを正式始動する。
目的は明確だ。SO-101ロボットアームを使ったSim2Real実装の全過程を通じて、エンジニアがPhysical AIの設計パターンを身体知として習得する。そしてその体験と記録が、この分野での受託開発という新しい事業の基盤になる。
本記事はそのキックオフ宣言であり、2年間の実行設計の全公開だ。

✅ この記事の結論(TLDR)
  • 技術的目標:SO-101ロボットアームを使ったBehavior Cloning(模倣学習)からSim2Realまでの完全な学習パイプラインをチームで実装する。最終ゴールは実機成功率85%の達成と、設計パターンの完全なドキュメント化だ。
  • プロジェクトの本質:これはエンジニア育成プロジェクトだ。Physical AIという新設計パターンを先行体験することで、アープはこの分野の受託開発を担える体制を整える。動くロボットを作ることよりも、その過程でエンジニアが何を習得するかが問われる。
  • PM方針:「チャレンジ→観察→クイックピボット」。未知の領域に踏み込む以上、最初から正解を求めない。やってみて、結果を観察して、ダメなら素早く方向を変える。この方針を体現するためにスパイラルモデルを採用した。
  • 記録の方針:設計判断・失敗・立て直しの全過程をArpable記事・YouTube動画・SNSでオープンにする。この記録の総体が「THE PACKAGE」となり、同じ挑戦をする次のチームへのベンチマークになる。

目次

このプロジェクトはなぜ始まるのか:ビジネス戦略としての先行体験

「2年後に、アープはPhysical AIを語れる会社になっている。」

アープは受託開発を主業とするソフトウェア企業だ。これまでAI・画像処理・組込み開発で積み上げてきた実績がある。そのアープが今、Physical AIという新しい領域を正面から取りに行く。

理由はシンプルだ。Physical AIの設計パターンは、従来のソフトウェア開発とは根本的に異なる。カメラ入力から学習・推論・実機制御までを一本のパイプラインで繋ぐEnd-to-End設計、シミュレーションで数千回の試行を圧縮するSim2Real、現実世界の多様性に動じない汎化性能の設計——これらは、実際に手を動かして体験した者にしか分からない知識だ。

大企業はこの体験を研究所単位で先行している。スタートアップは資金と人材を集中させている。では、アープのような規模の会社はどうするか。「先行体験」を組織的に設計し、実行するしかない。

このプロジェクトが2年間で目指す到達点は3層ある。

第一層は技術習得だ。SO-101ロボットアームにSim2Realで自律制御の知能を与える。ピック&プレースという基本タスクを起点に、汎化性能の設計パターンを習得する。

第二層はエンジニア育成だ。参加エンジニアは、ソフトウェア開発の経験を持つ実力者だ。しかしPhysical AIの設計パターンはこれまでのプロジェクトとは異なる。この「新領域への挑戦」を通じて、設計の判断基準・デバッグの作法・失敗から立て直す方法を身体で覚える。品質より体験、体験よりエンジニアの育成——これが今回のプロジェクトの優先順位だ。

第三層はビジネス基盤の構築だ。2年間の全過程を記録したTHE PACKAGEと、Arpableでの連載・YouTube動画・SNS発信が積み上がることで、アープはPhysical AI開発の実践知を持つ会社として認知される。これが次の受託案件への直接の橋渡しになる。

動くロボットを作ることはゴールの一部に過ぎない。このプロジェクトが本当に作り上げるのは、Physical AI開発を担えるエンジニアと、その証跡としての記録だ。


このプロジェクトで何を学ぶか:Sim2Real技術学習の地図

Real-to-RealからSim2Realへ。設計パターンを段階的に習得する2年間の学習ロードマップ。

このプロジェクトは単一の技術を学ぶのではなく、「AIロボットに知能を与える完全なパイプライン」を段階的に習得することを目的としている。各フェーズで何を学ぶかを先に示す。

1年目で学ぶ設計パターン(Real-to-Real)

学習① Behavior Cloning(模倣学習)の設計
人間がアームを手動で動かして「お手本」を見せ、そのデータからAIに動作を学習させる。「50〜100回のデモが数万コマの学習データになる」という設計は、データ収集のコスト感覚を根本から変える体験だ。カメラ→PC→アームの制御パイプラインをEnd-to-Endで繋ぐ設計を実装レベルで理解する。

学習② 再現性設計の作法
「昨日は動いたが今日は動かない」という不安定さを、物理的な標準化で排除する。ネジの締め具合・ケーブルの取り回し・照明条件——これらを「変数」として管理する発想は、従来のソフトウェア開発にはない設計作法だ。

学習③ 意図的な失敗からの堅牢性設計
照明を変える・初期位置をずらす・グリッパーの把持位置をわずかにずらす——意図的に「崩す」ことでAIの弱点を特定し、それを言語化してモデルを改善する。「なぜ失敗するのか」を設計的に分析するプロセスが、2年目のSim2Realを支える基盤になる。

2年目で学ぶ設計パターン(Sim2Real)

学習④ デジタルツイン設計
SO-101の物理特性(重量・重心・関節の摩擦)をURDFデータで正確に記述し、NVIDIA Isaac Sim上に「物理的に正しい仮想分身」を構築する。この「リアルとバーチャルの一致度」の設計が、Sim2Real成功率を決定する最初の関門だ。

学習⑤ Domain Randomization(領域ランダム化)設計
シミュレーション内のテクスチャ・照明・摩擦係数をランダムに変化させながら学習させる。現実では1回ずつしかできない練習を、シミュレータ内で数千台同時に24時間回し続ける。「汎化性能をどう設計するか」という問いへの実践的な答えをここで得る。

学習⑥ Sim-to-Real Gap分析とFine-tuning設計
シミュレーションと現実の「わずかなズレ」を計測し、言語化し、実機での追加学習で埋める。このGap分析の作法こそ、Sim2Real実装の最大の実践知だ。

📌 技術学習マップ:フェーズと習得パターンの対応
技術学習マップ
クール フェーズ 主な習得パターン
クール1 基盤構築 End-to-Endパイプライン設計・再現性設計
クール2 初回動作 Behavior Cloning実装・データ収集設計
クール3 堅牢化 意図的失敗分析・モデル改善ループ
クール4 型の完成 3回連続成功認定・THE PACKAGE v1.0
クール5 デジタルツイン URDF設計・物理特性モデリング
クール6〜7 Sim2Real学習 Domain Randomization・並列学習設計
クール8 実機転送 Fine-tuning・Sim-to-Real Gap設計
クール9 完了 成功率85%・THE PACKAGE最終版

チーム設計:誰が、どの役割で、どう動くか

エンジニアが新領域に挑む——そのための役割設計だ。

参加メンバーはそれぞれ、ソフトウェア開発・プロジェクトマネジメント・システム設計の実績を持つエンジニアがいる。
しかしながら、Physical AIの設計パターンはこれまでのプロジェクトとは異なる領域、つまり我々エンジニアは「これまで未踏な世界に踏み込む」「開拓者」なのだ。

チーム構成は「PM1名・水先案内人(アーキテクト)1名・実装エンジニア2名・アドバイザー2名」。

水先案内人(アーキテクト)という役割の設計には明確な意図がある。
尾崎の役割はアーキテクト兼水先案内人だ。自分が実装するよりも先に技術的な道を調査・判断し、川崎・太田が週4時間という限られた時間の中で最も効率的にPhysical AIの設計パターンを習得できる環境を作ることが最大の責務だ。
川崎・太田が新設計パターンの習得に集中できるのは、尾崎が先に技術的な道を切り拓いているからだ。

実装エンジニア2名で1体のアームを担うのは、日常の主業務が多忙になってきたときのリスク分散も兼ねている。つまり本業繁忙でどちらかが欠席した週でも作業が止まらない。加えて、2名が同じ技術課題に取り組むことで設計知識がメンバーに定着しやすくなる。

アドバイザー(成人・浩)の役割は明確だ。本業(ALT2026での別テーマ調査)を最優先としているが、本プロジェクトに関しては「いつでも相談できる存在」であり、広範な技術的知見から判断を助けるレフェリーとしても機能することができる。

プロジェクトチーム構成(週4h/人)
役割 氏名 主な責務
PM・統括 狩野 計画立案・進捗管理・Arpable記事化・動画制作・YouTube/X/LinkedIn/Note投稿
水先案内人
(アーキテクト)
尾崎 先行技術調査・技術方針判断・川崎太田への設計パターン習得支援
実装エンジニア A 川崎 実機組立・ソフト実装・データ収集
実装エンジニア B 太田 実機組立・ソフト実装・データ収集
アドバイザー 成人・浩 広範な技術知見からの助言(ALT2026 別テーマ調査が本業)
スポンサー:阿部社長(正式承認済)/ 業務管理部:発注手続き・会議室管理を担当

 なぜスパイラルモデルを選んだか:手法は目的に従う

アジャイルでもウォーターフォールでもない、第三の選択肢。

手法の選定は、このプロジェクトが最初に下した技術判断だ。

アジャイル(Scrum)の前提は「ベロシティが計測できること」と「スプリント毎に動くプロダクトが出ること」だ。
今回のプロジェクトでは、例えばPhysical AIのEnd-to-Endパイプラインで1スプリントに何ができるかは、やってみるまで分からない。
つまり、ベロシティが定義できない段階では、アジャイルの仕組みは機能しない。

ウォーターフォールは論外だ。「Sim2Realで何が起きるか」は実際にやってみないと分からない。要件定義の段階で全工程を確定することはこの種のプロジェクトでは不可能だ。

スパイラルモデルを選んだ理由は一つだ。「わからないことがある」を前提に設計された最も有効な手法の一つである。

スパイラルモデルは「計画→リスク分析→実験・試作→評価」のサイクルを繰り返す。各サイクルで「最大のリスクに最優先で取組む」ことが目的であり、何がリスクかすら最初は分からない探索型プロジェクトに、この方式はマッチしている。

このプロジェクトのPM方針を一言で表すと「チャレンジ→観察→クイックピボット」だ。未知の領域に踏み込む以上、最初から正解を求めない。やってみて、結果を観察して、ダメなら素早く方向を変える。
この方針はスパイラルモデルと同じ思想から来ている——「最大のリスクを1つ潰す」サイクルを回すとは、「やってみて、ダメなら即座に方向を変える権限をチームに与える」ことだ。方針転換は失敗ではない。スパイラル開発の重要な設計指針の一つだ。

スパイラルモデルの「クール制」への翻訳

本プロジェクトでは、スパイラルの1サイクルを「クール」と呼ぶ。
1クール=2ヶ月なので4名×週4時間×8週=128時間が1クールの投入工数だ。
「スプリント(アジャイル)」や「イテレーション(RUP)」ではなく、「クール」という独自語をあえて定着させることにした。
このプロジェクト固有の用語だが、それだけ「新領域への挑戦」という意味であえてこの用語を使用した。

各クールの構造はシンプルだ。最初の週に「今クールで潰すべきリスクを1つ決める」。
そして「実験・試作・記録」を行う。そして2か月ごとに設定しているクールALTでは、その成果と失敗による方向転換(クイックピボット)と次クールの計画を発表する。

但し、この構造自体もその時の状況次第で柔軟に変更可能となる。


軽量インセプションデッキ:このプロジェクトの「憲法」5条

チームの認識を揃える5枚のカード。最も重要な判断を先に全員で合意する。

インセプションデッキは、プロジェクト開始時にチームの認識を揃えるための合意文書だ。今回は本プロジェクト固有の問いに絞った5項目の軽量版を解説する。

CARD 1 ── NOTリスト:やらないことを先に決める

やらないことの最重要項目は2つだ。「本業時間を侵食する超過稼働」と「論文・学術発表」だ。

超過稼働を禁じる理由は持続可能性の担保だ。主業務を抱えるメンバーが前提のチームでは週4時間という制約は障壁ではなく設計条件だ。この制約のもとで2年間走り切ることが、このプロジェクトをベンチマークとして成立させる根拠になる。

論文・学術発表をNOTリストに入れた理由は、Arpable記事・YouTube動画・SNSという独自の発信経路がすでにあるからだ。学術論文の形式に縛られるより、実践的な知見をリアルタイムで世の中に届ける方がこのプロジェクトの性格に合っている。

CARD 2 ── 夜も眠れない問題:リスクを最初から見えた状態にする

リスクを「最初から見えていた」状態にしておくことが、スパイラルモデルでのリスク管理の核心だ

技術リスクを積極的に取りに行くこともある
我々は様々な可能性に挑戦していく。なぜなら未知な領域には様々な可能性を秘めているからだ。
例えば、水先案内人である尾崎は、ネイティブUbuntuが業界標準とされる中で「Windowsネイティブ環境でLeRobotとSO-101がどこまで動作するか」の検証に取り組むことにした。これはPMの承認の共におこなう「チャレンジ→観察→クイックピボット」の最初の例となる。

CARD 3 ── トレードオフスライダー:このプロジェクト固有の優先順位

このプロジェクトでは、品質よりも体験、体験よりもエンジニアの育成を優先する。これは通常開発との意図的な逆転だ。

弊社では通常の受託開発においては品質を最優先にしている。
しかし今回のプロジェクトでは道領域のPhysical AIという新設計パターンの習得自体が最優先事項だからだ。
つまりこのプロジェクトでは「完璧な成果物を作ることではなく、設計上の判断を下した根拠を記録すること、失敗から何を学んだかを言語化すること」が最重要事項となる。

CARD 4 ── チーム構成

PM・水先案内人・実装エンジニア2名・アドバイザー2名の5名体制。役割設計の思想と育成方針は「3. チーム設計」で詳述している。

CARD 5 ── スケジュール・ガバナンス・発信フロー

2ヶ月1クールのスパイラル制で9クール2年間を走る。
全貌は「6. 9クール制スケジュール
補足:このプロジェクトにおけるロードマップの考え方
7. ガバナンス設計
で詳述している。


9クール制スケジュールの全貌

1年目はReal-to-Realで「型」を作り、2年目はSim2Realで「知能」を加速させる。

1年目(2026年):Real2Realの 基盤確立

1年目のキーワードは「型(Kata)」、すなわちreal2realの実現だ。
この目標に関しては「昨日は動いたが今日は動かない」という不安定さを徹底的に排除し、誰がやっても同じ結果が出る再現可能な状態を作ることが1年目のメインミッションだ。

  1. クール1(4〜5月)では機材調達・物理標準化・開発環境構築を行う。
  2. クール2(6〜7月)ではBehavior Cloningを使ったEnd-to-End最小ループの初回成功を目指す。
  3. クール3(8〜9月)では意図的に環境を「崩す」ことでAIの弱点を分析し、堅牢性を高める。
  4. クール4(10〜11月)では3回連続成功という定量的マイルストーンを達成し、THE PACKAGE v1.0を完成させる。

その後12月〜1月をバッファ期間として確保する。クール4に遅延が生じた場合の挽回策としての検討期間として使用することもできるが、これを積極的には利用することはしない。2年目に持ち越すことを優先して検討していく。

2年目(2027年):Sim2Real 実装

  1. 2年目はシミュレーションの力を借りて知能を加速させる。
  2. クール5(2〜3月)ではNVIDIA Isaac Simを使ったデジタルツイン(SO-101の仮想分身)を構築する。URDFデータによる物理特性の正確な再現が最初の壁だ。
  3. クール6〜7(4〜7月)ではIsaac Lab上でのDomain Randomizationと並列学習を実施する。現実では1回ずつしかできない練習を、シミュレータ内で数千台同時に24時間回し続ける。
  4. クール8(8〜9月)ではFine-tuningによる実機デプロイを行う。
  5. クール9(10〜11月)で実機成功率85%の達成と最終THE PACKAGEの公開をもってプロジェクト完了となる。
9クール制のロードマップ(2026年4月7日時点)
クール 期間 主要テーマ 成功指標
クール1 2026年4〜5月 機材調達・物理標準化・開発環境構築 全軸動作確認
クール2 2026年6〜7月 Behavior Cloning初回動作 最小ループ成功
クール3 2026年8〜9月 堅牢化・失敗分析 弱点言語化
クール4 2026年10〜11月 型の完成・THE PACKAGE v1.0 3回連続成功
クール5 2027年2〜3月 デジタルツイン構築・URDF統合 仮想SO-101完成
クール6 2027年4〜5月 Domain Randomization・並列学習開始 学習ループ稼働
クール7 2027年6〜7月 並列学習検証・Sim-to-Real Gap分析 Gap言語化
クール8 2027年8〜9月 Fine-tuning・実機デプロイ・成功率検証 実機で動く
クール9 2027年10〜11月 最終THE PACKAGE確定・プロジェクト完了 成功率85%
総投入工数:約1,000〜1,300時間 / プロジェクト完了:2027年11月

補足:このプロジェクトにおけるロードマップの考え方

当初のロードマップは持つが、クールALTごとに見直して、実現可能な最新のロードマップを更新していく。

Physical AIとSim2Realは、チーム全員にとって初挑戦の領域だ。最初から細部まで定義した計画を置くことは合理的ではない。むしろ、各月の活動で得られた知見を反映しながら見直し続けることで、ロードマップの信頼性は段階的に高まっていく。

月単位で計画が変わることは弱さではない。探索型プロジェクトにおいて、計画が成熟していく自然なプロセスである。

固定するもの

  • 週4時間という制約条件
  • 2年間でPhysical AIの設計パターンを身体知として習得するという到達目標
  • スパイラルモデル/クール制という運営方式
  • PM・水先案内人・実装エンジニア・アドバイザーという役割分担
  • 設計判断・失敗・立て直しを記録し、発信するという方針

現時点で確定している直近アクション

キックオフの時点で確定しているのは、直近3回の活動のみである。それ以降の内容は、各回で顕在化した課題のうち、影響度と緊急度の高いものから順に対応する

📌 直近で確定している活動日
直近3回の活動予定
日程 形式 目的
第1回:4月7日(火)20:00〜21:00 リモート会議 新メンバーにALT2026キックオフ資料を説明し、その後AIロボット制作プロジェクトの全体像を共有する。この記事をベースに、NotebookLMで動画・音声・スライド・インフォグラフィック教材も作成し、理解の初期速度を揃える。
第2回:4月14日(火)20:00〜21:00 リモート会議 Physical AI開発に関するやや詳細な技術説明を行い、チーム全員の前提知識を揃える。ここでもNotebookLM由来の補助教材を活用し、予習前提で議論の質を高める。
第3回:4月24日(金)17:00〜19:00 オフ会(事務所集合) SO-101ロボットアームを実際に組み立てる。水先案内人が先行して目処を立てた内容をもとに、実装エンジニア2名が手を動かし、初回の実機体験を行う。必要に応じて撮影し、編集後YouTubeへ記録を残す。ここで発生した問題を全員で議論し、5月に優先して潰すべきリスクを決める。

なお、第3回終了後は、社長との会食を兼ねたキックオフ懇親会を行い、現時点での状況報告と今後の方向性を共有する予定である。

7. ガバナンス設計:クールALTと定例の全設計

アープ・ライトニングトークをプロジェクトの背骨に組み込む。

クールALT(アープ・ライトニングトーク)の実施

クールALTは各クール末に実施する全社員向けLT(ライトニングトーク)形式のレビュー会だ。(火曜日 20:00〜21:00 リモートで実施する予定)

「失敗を報告することが評価される場」を作ることが、このプロジェクトを走り切るための重要な組織文化的条件だ。失敗を隠すチームは同じ失敗を繰り返す。クールALTはその逆の文化を組織に根付かせる仕組みとしてのだ。

クールALT #1は2026年5月26日(火)20:00〜21:00に開催する予定だが、これは4月24日時点で判断する。

定例会の開催

定例会は毎週火曜日 20:00〜21:00の1時間を基本とする。
ただし各クールの第3週は例外で、金曜日 17:00〜19:00 に事務所でのオフ会形式に変更する。ロボットアームが1体しかないため、実機を使った作業・確認は必ず全員が集まるオフ会で行う。
リモートでは実機の細かな物理的問題(ネジの締め具合、ケーブルのたわみ、グリッパーの把持感)は共有できないためだ。

クールALT後の発信フロー

クールALT終了後、以下の順序で外部発信する。

クールALT(全社LT)→ Arpable 記事配信 → YouTube 動画 → X(旧Twitter)投稿 → LinkedIn 投稿 → Note 投稿

記事と動画がTHE PACKAGEの中核を担う。スライドで発表した内容を記事として完全再現し、制作過程を動画で記録する。この連鎖がアープの実践知を世の中に届けるパイプラインだ。


8. THE PACKAGEとは何か:このプロジェクトの最重要成果物

THE PACKAGEとは、本プロジェクトが体験したことの「再現可能な実践知の総体」だ。一般的な用語ではなく、このプロジェクト固有の成果物名として定義する。

THE PACKAGEが内包するのは以下の要素だ。

  • 目標としたこと。
  • 実現したこと。
  • 試作ー検証ー改善の記録

THE PACKAGEはクールごとに更新される。うまくいったことだけを書くのではなく、失敗とその原因、そして次回どう立て直すかまでを記録対象にする。プロジェクト完了後にはArpableで最終版を公開する。


クール1 定例・オフ会スケジュール

クール1 定例・イベント一覧
日程 種別 形式・場所 主な議題・目的
4/7(火) キックオフ 20:00〜21:00 リモート ALT2026資料共有・本プロジェクトの説明と検討・役割確認・THE PACKAGEテンプレート着手
4/14(火) 第2回定例 20:00〜21:00 リモート Physical AI技術説明・W1進捗確認・ブロッカー解消・THE PACKAGEテンプレート完成
4/24(金) 第1回オフ会+キックオフ会食 17:00〜19:00 事務所(実機あり)+会食 SO-101全員での実機制作・全軸動作確認。終了後、阿部社長も加えたキックオフ会食を開催
4/28(火) GW休み 定例なし 自習継続(THE PACKAGE記録・物理標準書完成)
5/5(火) GW休み 定例なし 自習継続(カメラ接続・LeRobotテスト)
5/12(火) 第3回定例(ADV参加) 20:00〜21:00 リモート 成人・浩 参加・統合テスト進捗確認・技術課題の助言
5/22(金) 第2回オフ会 17:00〜19:00 事務所(実機あり) LTリハーサル・THE PACKAGE最終記録・クールALT #1 準備完了確認
5/26(火) クールALT #1(全社LT) 20:00〜21:00 リモート 全社員向けLT発表・THE PACKAGE最終版提出・クール2計画承認
GW期間(4/28・5/5)は定例なし・自習継続。業務管理部:会議室管理を担当。

10. よくある質問(FAQ)

なぜ週4時間という制約を変えないのですか?

この制約は障壁ではなく設計条件です。本業を侵食せずに2年間走り切れること自体が、このプロジェクトを再現可能なベンチマークにします。

なぜ最初からSim2Realに入らないのですか?

Sim2Realの前に、実機側で再現性のある「型」を作る必要があるからです。Real-to-Realで再現性を作れないチームは、2年目にシミュレーションとのGapを正しく分析できません。

ロードマップが月単位で変わるのは問題ではないのですか?

問題ではありません。本プロジェクトでは2年間のロードマップを持ちますが、それは固定WBSではなく、探索に応じて更新される仮説地図です。月単位の見直しを繰り返すことで、むしろ信頼性は上がります。

なぜクールALTを全社員向けに開くのですか?

失敗分析を全社員の前で発表する習慣が、組織全体の学習速度を上げるからです。

Arpableでの外部発信・YouTube動画・SNSと社内ALTを連動させることで、社内外に一貫したナレッジ共有サイクルが完成します。


まとめ:アープはなぜ今、Physical AIに挑むのか

このプロジェクトは「できるかどうか分からない挑戦」ではない。「どうやって設計するかを学ぶ」ための、意図的な先行体験だ。

スパイラルモデルは最初から完璧さを求めない。クール1を完走したチームが立てるクール2の計画は、今より必ず精度が高い。クール4を完走したチームが設計する2年目は、1年前には想像もできなかったほど具体的になるはずだ。
計画の精度はクールを重ねるごとに上がる——それがスパイラルの本質だ。

Physical AIの設計パターンを身体で知るエンジニアが育ち、その記録が世の中に届き、次のプロジェクトへの問い合わせに繋がる。それがアープがこのプロジェクトに賭けている未来だ。

クール1の最初の一手は、今日だ。


専門用語まとめ

スパイラルモデル
ソフトウェア・システム開発手法の一つ。「計画→リスク分析→実験・試作→評価」のサイクルを繰り返し、各サイクルで最大のリスクを一つ潰しながら開発を進める。未知の領域が多いプロジェクトに特に適合する。
クール(本プロジェクト独自用語)
本プロジェクトにおける2ヶ月単位の活動期間。4名×週4h×8週=128時間が1クールの投入工数。スパイラルモデルの「一周」に相当し、クール末にクールALTを実施して次クールへの計画を更新する。
クールALT(アープ・ライトニングトーク)
各クール末に実施する全社員向けLT(ライトニングトーク)形式の社内レビュー会。成果・失敗分析・THE PACKAGE更新内容を発表し、次クールの課題をチームで合意する。火曜 20:00〜21:00 リモート開催。
THE PACKAGE(本プロジェクト独自用語)
本プロジェクトの最重要成果物。「知らない人が読んで再現できる」水準の手順書・トラブルシューティング表・失敗記録・設計判断ログ・制作動画の総体。クール毎に更新され、プロジェクト完了後にArpableで最終版を公開する。
水先案内人(アーキテクト)
本プロジェクトにおけるアーキテクト兼エンジニア育成担当の役職名。チームが未知の技術的課題に直面する前に道を切り拓き、若手エンジニアへの設計パターン習得支援を担う。
Behavior Cloning(模倣学習)
人間がロボットを手で動かして「お手本」を見せ、そのデモンストレーションデータからAIに動作を学習させる手法。50〜100回のデモで数万コマの学習データが生成される。LeRobotが採用する主要な学習手法の一つ。
Sim2Real(シム・トゥ・リアル)
シミュレーションで学習させたAIモデルを現実のロボットに転送して動作させる技術。データ収集コストを劇的に削減できる一方、シミュレーションと現実の差異(Sim-to-Real Gap)を埋める作業が最大の難関となる。
Domain Randomization(領域ランダム化)
シミュレーション内のテクスチャ・照明・摩擦係数などをランダムに変化させながら学習させる手法。現実世界の多様な環境に動じない汎化性能の高い知能を育てるための技術。
インセプションデッキ
プロジェクト開始時にチームの認識を揃えるためのドキュメントセット。Jonathan Rasmussonが提唱した手法で、プロジェクトの「なぜ・誰が・何を・やらないこと・優先順位」を明文化する。本プロジェクトでは5項目の軽量版を策定した。

参考サイト・出典

更新履歴

  • 2026年4月7日:初版公開(プロジェクト正式キックオフ日)

以上

ABOUT ME
ケニー 狩野
ケニー狩野(Kenny Kano)。AI社会実装・技術経営・ITコンサルティングを専門とする経営者・監修者。株式会社ベーネテック代表、株式会社アープ取締役、一般社団法人Society 5.0振興協会 AI社会実装推進委員長。中小企業診断士・PMP・ITコーディネータ。早稲田大学大学院理工学研究科修了後、キヤノン株式会社にてエンジニア・プロジェクトマネージャとして国内外の開発を牽引。中国・インド・オーストラリアを含む海外オフショア案件も経験。独立後はAI社会実装・技術経営支援に転向。Arpableにて人工知能・先端技術分野の記事を約2年間で約300本監修。著書『リアル・イノベーション・マインド』(2018年)。詳細プロフィール:https://arpable.com/kenny-kano/