Microsoft Project

Horizun Project MCP

Java も Microsoft Project も不要で、書き込んだ内容について正確に報告する、Microsoft Project 用の MCP サーバーです。

ソフトウェアの操作担当ではなく、PMO として動作します。 お客様に代わって Microsoft Project を操作するだけではありません。PMBOK に従い、プロジェクトマネジメントオフィスのように計画、管理、報告を行います。100％ルールに準拠した WBS、コストを組み込んだベースライン、出来高とアーンド・スケジュール、定量的なスケジュールリスク、理由と承認者を伴う正式な変更管理、PPC を用いた週次の先行計画、そして傾向を含む期間状況レポートを扱います。Project はエンジンであり、手法こそが製品です。

Español

任意の MCP クライアントから .mpp、Primavera の .xer、または MSPDI の .xml を指定し、重要な質問をしてみてください。クリティカルパスはどこを通るのか、どのリソースが過剰割り当てになっているのか、スケジュールは DCMA の監査に耐えられるのか、2 週間の遅れが実際に完了日にどのような影響を与えるのか。変更を書き戻した後は、どの変更が反映されたのかも把握できます。報告する前に、変更の一つひとつをモデルから再読み込みして確認するためです。

dotnet tool install -g HorizunMsProjectMcp

インストールはこれだけです。JVM も Microsoft Project もライセンスも不要です。単独で読み込み、スケジュールを作成します。

クライアントを接続する

クライアント	操作
Claude Desktop	Releases から .mcpb をダウンロードし、Settings → Extensions にドロップします。MCP サーバー自体がインストールされるため、事前に実行するものはありません。
Claude Code	claude mcp add horizun-msproject-mcp -- horizun-msproject-mcp
Codex	codex mcp add horizun-msproject-mcp -- horizun-msproject-mcp
ChatGPT	stdio サーバーの前段に HTTPS ブリッジが必要です。方法と、まず検討すべき点はこちらです。

プラグインを使った方法やアンインストールを含む、クライアントごとの詳しい手順は docs/INSTALL.md をご覧ください。

---

なぜこれを選ぶのか

Microsoft Project の MCP サーバーはいくつかあります。どれも Java、ライセンス済みの Microsoft Project のインストール、または有料の JDBC ドライバーが必要で、このサーバーを開発したマシンでは、どれも起動しませんでした。ここにある8つの機能は、ほかではどこにもありません。

前提条件ゼロ	単一の .NET バイナリです。MPXJ は IKVM を通じて .NET 向けにコンパイルされるため、JVM は一切不要で、Microsoft Project も必要ありません。
模倣ではなく、Microsoft Project の日付	Project がインストールされている環境では、このサーバーが報告するすべての日付を Project 自身が計算します。実際の7つのスケジュール（タスク8,823件）で、このサーバー経由の再計算と編集は、すべてのタスクで分単位まで Project と一致しました。方法はこちら。
検証済みの書き込み	Microsoft Project は、日付の自動スケジュール、ハード制約、サマリーのロールアップ、計算済みコストなどへの書き込みを頻繁に、しかも黙って無視します。モデルから読み戻して一致を確認するまでは、ここでは適用済みと報告しません。
DCMA 14項目評価	スケジュールを実行可能かどうか判断する業界標準です。Primavera のサーバーはこれを実装していますが、Microsoft Project のサーバーには一つもありません。チェック12では、600日の遅延を実際に注入して、何が動くかを測定します。
誰もリンクしていないロジックを復元	バーチャート上では正しく配置されているのに、一度もリンクされていないスケジュールは、最もよくある不具合です。DCMA はこれを検出しますが、修正するものはありません。日付にはすでに順序が示されているため、この機能はそこから順序を読み取り、繰り返し全体で同じ順序が保たれることを検証して、欠落しているリンクを提案します。
測定に基づく再計画	回復案はスケジュールのコピーに適用して再スケジュールし、実際に得られた完了日とともに報告します。何も回復できない案は、アドバイスとして提示せず、その旨を伝えます。
過去のプロジェクトから学習	完了済みのスケジュールを指定すると、各作業の実際の所要時間と、通常その前に行われる作業を報告し、それを基に新しい工程計画を作成します。単位ごとに1タスクを割り当て、各職種が実際に従った順序で並べます。
BIM ブリッジ	コードでスケジュールのタスクをモデル要素に結び付け、計測した数量を期間の提案に変換し、Navisworks の4D表示や Power BI の進捗ダッシュボードを動かす要素別の日付を出力します。これを行うものはほかにありません。

---

27個のツール

セッション — project_health · project_open · project_save

project_health は単なる ping ではなく、診断ツールです。Microsoft Project を検出し、COM サーバーが実際に起動するかをテストします。起動しない場合は、HRESULT による診断と修復手順を返します。これは仮定の話ではありません。このマシンでは、有効な登録が存在するにもかかわらず CO_E_SERVER_EXEC_FAILURE が発生し、出力された修復手順の最初のステップで解決しました。

読み取り — project_info · tasks_query · links_query · resources_query · timephased_query

フィルター、ページ分割、フィールド選択に対応しています。タスクは安定した uid で指定します。行の id は表示専用です。タスクを挿入するとすぐに値が変わり、これで指定すると別のタスクを編集してしまうためです。

分析 — schedule_analyze · schedule_qa · baseline_compare

サーバー側で計算するため、エージェントは2,000件のタスクをコンテキストに取り込む代わりに質問できます。クリティカルパス、フロートの分布、支配パス、日ごとの全体的な過剰割り当て、DCMA-14、完全なアーンドバリュー（BCWS／BCWP／ACWP、SPI、CPI、EAC、TCPI）に対応しています。スケジュールにコストがあればコスト単位、作業時間があれば時間単位、どちらもない場合（大半はこちら）は期間で重み付けします。レポートには、どの方法が使われたかが記載されます。

書き込み — tasks_write · links_write · resources_write · calendars_write · schedule_update バッチ処理、型付き、検証済みです。循環は適用前に拒否され、問題のあるチェーンが明示されます。 カレンダーは全体を編集できます。稼働週とその時間（半日または終日の土曜日、シフト）、 稼働日と非稼働日の例外およびその時間、プロジェクトカレンダー、タスクとリソースの カレンダーを設定します。タスクでは、タイプ、作業量駆動フラグ、固定費、基準日程の日付を 変更しない基準コスト、アウトライン全体を一括で設定します。リソースでは、Project が実際に 認識する単価、時間外勤務単価、資材単位数、最大単位数を設定します。schedule_update の level_resources 操作では、Microsoft Project 独自のレベラーを使って平準化します。必要に応じて 余裕時間内のみに限定できます。提供していない機能がひとつあります。アウトライン内でタスクを 別の位置へ移動することです。これを要求すると、その機能名を示して拒否します。中途半端に 動作する操作は、存在しない操作よりも悪いからです。

計画 — schedule_recovery · schedule_scenarios · schedule_target · schedule_sequence · schedule_learn · schedule_generate

再計画は、主張ではなく測定に基づいて行います。schedule_recovery は遅れている作業を見つけ、 スケジュールのうちどれだけがその後ろにあるかに基づいて順位付けし、各リカバリー策を順に 試します。支配経路上のラグをなくす、先行タスクが半分完了した時点で引き継ぎを重ねる、 最長のクリティカルタスクを圧縮する、土曜日を終日稼働にする、そしてこれらすべてを組み合わせる、 という各策を使い捨てのコピー上で試し、それぞれが実際にもたらす完了日と、策が却下された場合は その理由を報告します。schedule_scenarios は、定義した代替案（カレンダー、リソース、タスク、 ロジックの変更をまとめたもの）を並べて比較します。完了日、コスト、過剰割り当て、クリティカル タスクを確認でき、変更は一切反映されません。schedule_target は提示された日付を検証し、 ネットワーク上でその日付が維持できない作業を明示します。schedule_sequence は、スケジュールが すでに示している日付の順序を読み取り、不足しているロジックを復元します。プランナーが作業を 正しく配置したものの、リンクを設定しなかった場合、その判断を復元できます。schedule_learn は 完了したスケジュールから、各作業に実際にかかった期間と、通常その前に行われる作業を抽出します。 schedule_generate はその情報から初稿を作成します。アパートまたはフロアごとにひとつのタスクを 作り、履歴に基づいて各職種の作業を順序付けます。

モデルのエクスポートをスケジュールと一緒に schedule_learn に渡すと、共通のコードを使って 数量とタスクを結び付け、生産性、つまり作業班が実際に1日でこなした量を測定します。 次に schedule_generate は、記憶された期間をそのままコピーするのではなく、新しいプロジェクトの 数量から期間を算出します。プロジェクト間で引き継がれるのは生産率であり、変わるのは数量だからです。 スケジュールごとにエクスポートをひとつ、同じ順序で指定してください。生産率はプロジェクトごとに 測定されます。プロジェクトをまたいで数量を合計すると、どの生産率も過大になります。

初稿の作業順序は、学習元のスケジュールの順序を超えることはできません。参照元では、各アクティビティが 作業単位ごとに同じアクティビティ自身にはリンクされていても、周囲の職種にはリンクされていない場合、 両ツールがそのことを伝え、件数も示します。ライブラリは、自分自身以外の先行タスクを学習した アクティビティ数を報告し、初稿は、その前に何も予定されなかった職種の数を報告します。

プロジェクト管理 — schedule_risk と、上記ツールの PMO 関連機能

• 定量的なスケジュールリスク（schedule_risk）：ネットワーク独自のロジックと、4 種類すべてのリンクタイプおよびラグを対象にモンテカルロシミュレーションを実施します。各タスクの三点見積もり範囲またはデフォルトのばらつきを用い、プロジェクトカレンダーの稼働時間で計算します（土曜日の半日稼働と経過時間ラグを含みます）。スケジュール独自の完了日を基準とするため、最頻値の実行結果はスケジュールと一致します。P10／P50／P80／P90 の完了日、目標およびベースラインの達成確率、P80 コンティンジェンシー、重要度と感度によるリスク要因を算出します。シードを指定した実行は常に同じ結果になります。
• 期間ステータスレポート（schedule_analyze の aspect status_report）：計画値と出来高、SPI、CPI、アーンド・スケジュール SPI(t)、3 種類の方法による EAC、TCPI、完了日の予測、リスクのあるマイルストーン、上位の問題、記録されたすべての締め日の推移を表示します。
• コストを割り当てたスケジュール（schedule_update の op load_budget）：コードごとの予算を読み込み、同じコードで BIM リンクを設定し、コストとしてタスクに配分します。タスクに割り当てられていない明細も報告されます。timephased_query の measure s_curve は、コストが読み込まれている場合、PV、EV、AC の累計を金額で返します。
• 統合変更管理：ベースラインの再設定には reason が必須です（approvedBy も記録されます）。すべてのベースライン、予算の読み込み、確定した編集バッチについて、完了日への影響を含めてログに記録します（aspect change_log）。
• 短期計画（aspect lookahead）：次の数週間の作業について、各タスクの制約、準備完了か制約ありか、前週に記録したコミットメントに対する PPC（ラストプランナー）を表示します。
• WBS の規律：schedule_qa は 100％ルール（空のサマリー、サマリー上のコストまたはリソース、重複する WBS コード、子が 1 つだけのサマリー）を検証します。project_export の format wbs_dictionary は WBS ディクショナリを書き出します。

履歴（締め日、コミットメント、変更）はスケジュールと並んで <name>.hzpmo.json に保存されるため、次に .mpp を書き込むツールが何であっても保持されます。

相互運用性 — project_export · project_import · bim_link · bim_sync

CSV、JSON、MSPDI、Primavera XER、PMXML、ネイティブの .mpp、および整形済みの Power BI データセットに対応しています。インポートでは、書き込む前に計画を立てます。

読み込み時に必要なコスト

27 個のツールで、サーバーが接続されている間、すべてのプロンプトに約 13,500 トークン分のスキーマが含まれます。この機能範囲を提供するための正直な対価であり、利用するかどうかを決める前に知っておく価値があります。また、機能範囲を 25 個前後に保つ理由でもあります。最大の代替製品では 79 個のツールが提供されており、ある程度を超えると、エージェントはその機能範囲を十分に把握できず、適切なツールを選べなくなります。

---

2 つの契約

検証が完了するまで、何も適用されません。

{
  "applied": 12,              // operations that fully succeeded, re-read from the model
  "fieldsVerified": 31,
  "rejected": [{
    "uid": 45, "field": "finish",
    "requested": "2026-09-10", "actual": "2026-09-14",
    "reason": "'finish' is calculated from the task's duration and its predecessors. Change the
               duration or the logic, or set a constraint, rather than writing the date."
  }],
  "impact": {
    "tasksMoved": 312,
    "projectFinishBefore": "2027-03-14", "projectFinishAfter": "2027-03-28",
    "criticalPathChanged": true, "newNegativeFloat": 8
  },
  "verifiedBy": "reread"
}

ドライランは実際のシミュレーションです。 dryRun: true はスケジュールをディープコピーし、バッチを適用して、クリティカルパスエンジンで再スケジュールし、差分を測定した後、コピーを破棄します。影響の数値は予測ではなく、実際に観測された値です。

---

機能の正確な説明

project_health は機能マトリクスを公開し、各ツールはそれに従います。ファイルバックエンドでは、次の 2 つの機能は false のままで、近似で代用せず、要求を拒否します。

• write_native_mpp — バイナリ形式を書き出せるライブラリはありません。Microsoft Project がインストールされている場合は、保存処理を Microsoft Project に委任し、本物の .mpp を生成します。インストールされていない場合は、MSPDI と説明を返します。
• level_resources — Microsoft Project のリソース平準化ヒューリスティックは公開されていません。模倣すれば、同じ名前を掲げる別の結果になってしまいます。

データがすでに含まれているベースラインへの上書き保存も、明示的に要求されない限り拒否されます。ベースラインは、すべての差異を測定する基準となる当初計画の記録であり、ファイル保存後に復元することはできません。

その他のすべての機能、つまりスケジューリング、再計算、ドライランシミュレーション、未完了作業の再スケジュール、DCMA クリティカルパステストは、どの環境でも動作します。日付を計算する主体については、次のセクションで説明します。

日付：Microsoft Project 独自のもの

Microsoft Project がインストールされている場合、日付は Microsoft Project が計算します。 再計算、書き込み後の再スケジュール、ドライラン、復旧オプション、目標日、DCMA クリティカルパステストでは、いずれもスケジュールを Project に渡して計算させ、計算された日付を受け取ります。 project_health は schedulingEngine: microsoft-project として報告します。

推測ではなく、実測に基づいています。7 つの実際の建設スケジュール（タスク数は 21～5,984 件、サマリータスクを含めて合計 8,823 件、分割タスク、進行中の作業、9 時間労働日、土曜日の半日勤務を含む）で、このサーバーを通じた再計算は、すべてのスケジュールの全タスクについて、分単位まで Microsoft Project の計算日付を再現し、進捗も Project と完全に同じ状態に保ちました。書き込みも同じ基準で検証しました。このサーバーで期間の変更、進捗率の変更、新しいリンクの追加を行った場合と、Project で同じ編集を手作業で行った場合とで、サマリータスクも含め、タスクごとに日付も進捗も一致しました。

実現には、Project でファイルを開くだけでは不十分でした。Project 独自の XML インポートでも Project の動作は再現されません。実際の 126 タスクのスケジュールでは、Project 独自の XML エクスポートでさえ、再度開くとすべてのタスクの日付が異なっていました。原因と、Project への受け渡しでの対処方法は次のとおりです。

• リソースが割り当てられていないタスク。 リソースのないタスクにもプレースホルダーの割り当てが設定されており、インポート時には、タスクのカレンダーではなくプレースホルダーリソースのカレンダーに基づいて Project がスケジュールします。タスクにすでに記載されている内容と重複する情報しかない場合は、その割り当てを除外します。
• 分割タスク。 作業の開始、中断、再開による空き期間は、割り当ての日ごとの作業時間にのみ記録されるため、その情報も一緒に受け渡します。
• 進行中の作業。 XML インポート後、進行中のタスクでは、完了済み作業の一部が残作業に移動することがあります。そのため、インポートから戻った進捗は決してそのまま使いません。書き込みによって変更する場合は、Project 独自のルールに従います。期間を延長すると完了済みの作業は維持され、新しい進捗率を設定するとタスクが開始または完了し、サマリーには Project と同じ方法で集計されます。
• 空白行。 Project で挿入して空のままにした行は Project にとってタスクではありませんが、読み込み時にはプロジェクト開始日に設定されたタスクとして扱われ、実際のスケジュールでは、その行に届くようにサマリーが 2 年前まで遡っていました。その行は空白行のまま受け渡します。

4,753 タスクのスケジュールの再計算には約 20 秒かかり、その大半は Project 内での処理時間です。

Project が開いている場合は、そのまま使用します。Microsoft Project は単一インスタンスのため、あらゆる自動化処理（このサーバーを含む）は、使用中の Project に接続します。そのため、このサーバーがウィンドウを隠したり、ドキュメントを再計算したり閉じたりすることはありません。自ら開いた一時コピーのみを操作し、各手順の前に、アクティブなドキュメントがそのコピーのままであることを確認します。処理後も、元からアクティブだったドキュメントが表示されます。

Microsoft Project がない場合

MPXJ はスケジュールファイルの読み書きはできますが、スケジュール計算は行いません。そのため、前進パスと後退パス、トータルフロートとフリーフロート、4 種類すべての関係タイプ、ラグ、制約、期限、実績日、各タスクの稼働カレンダーに対応した、独自のクリティカルパスエンジンも用意しています。macOS、Linux、Windows で Project がない環境では、このエンジンが動作します。

⚠️ このエンジンは Microsoft Project のスケジューラーではありません

このサーバーで作成したスケジュールでは Project の動作を正確に再現しますが、実際にインポートしたスケジュールでは再現しません。4 つの本番ファイルでは、Project 独自の開始日と一致したタスクの割合は、それぞれ 100%、69%、23%、23% でした。タスクの種類、作業量主導のスケジューリング、リソース主導の日付設定、手動タスクまたは分割タスク、経過期間には対応していません。そのため、Project がない場合でも、インポートしたスケジュールを暗黙に再スケジュールすることはありません。日付は、schedule_update op='recalculate' を指定してこのエンジンを明示的に実行するよう求めるまで、Project の日付のままです。その際は事前に警告します。読み取り、分析、DCMA-14、アーンドバリューは、ファイルにすでに記録されている日付に基づいて実行され、影響を受けません。

任意のクライアントへの接続

Claude Desktop、Claude Code、Codex については docs/INSTALL.md で説明しています。MCP over stdio に対応するその他のクライアント（Cursor、VS Code、独自のクライアントなど）については、次のとおりです。

{
  "mcpServers": {
    "horizun-msproject": {
      "command": "horizun-msproject-mcp"
    }
  }
}

レジストリ名：io.github.HorizunGroup/horizun-msproject-mcp（.mcp/server.json を参照）。

各セッションでは、最初に project_health を呼び出してください。使用中のバックエンドと、そこで実行できる操作がわかります。

ソースからのビルドとテスト

cd src/HorizunMsProjectMcp && dotnet build && cd ../..
python tools/acceptance-test.py   # 65 checks, all tools end to end
python tools/scheduler-test.py    # 45 checks, critical-path engine correctness
python tools/planning-test.py     # 52 checks, reprogramming and learning
python tools/robustness-test.py   # 34 checks, concurrency and hostile input
python tools/smoke-test.py        # 15 checks, environment and capabilities
python tools/packaging-test.py    # 33 checks, the metadata every client reads
python tools/imported-file-test.py   # 16 checks, building on a file Project saved
python tools/planner-features-test.py  # 32 checks, calendars, costs, outline, scenarios, read-only safety
python tools/project-engine-test.py  # 29 checks, Microsoft Project as the engine (needs Project)

Windows と Linux で、実行中のサーバーに対して実際の JSON-RPC を使用した 321 件のチェックを実行します。Microsoft Project がインストールされている場合、テストスイートでは Project が日付を計算します。また、project-engine-test.py は、サーバーと Project で同じ操作を手動で行った場合を比較します。タスクごとに日付、進捗、サマリーを比較し、開いている Project の状態が一切変更されないことも確認します。Linux ジョブは、主要な主張を裏付ける証拠です。JVM も Microsoft Project もないマシンで実行されます。

受け入れテストスイートでは、何もない状態から建設スケジュールを作成し、上記の仕様を満たすことを検証します。ドライランでは何もコミットされないこと、サイクルは適用前に拒否されること、不明な uid への書き込みは無視されず拒否されること、DCMA クリティカルパステストでは、終了日が注入された遅延と正確に同じ日数だけ移動することを確認します。

日付への信頼を支えるのが、スケジューラーのテストスイートです。開始から開始、終了から終了、開始から終了のロジック、正と負のラグ、厳密および柔軟な制約、負のフロートを生じさせる期限、実際にスケジュールを後ろ倒しにするカレンダーの例外、サマリーのロールアップを含む WBS 階層を網羅します。また、インポートしたスケジュールが暗黙に再スケジュールされないこと、Primavera XER と PMXML、および実際のバイナリ .mpp を通じた完全な往復変換もテストします。最後の .mpp は Microsoft Project 自身が書き出したものを MPXJ で読み戻し、日付、マイルストーンのフラグ、予算コード、依存関係がすべて保たれることを確認します。

テストスイートに加えて、サーバーは本番の建設スケジュール 2 件で、プランナーの一連の作業を通してテストされています。5,985 タスクのプログラムと、170 MB・1,937 タスクのプログラムを開き、監査、ベースライン設定、進捗記録、アーンドバリューの測定、Power BI データセットのエクスポートを行っています。また、最大 7,000 タスクのファイルも読み取っています。

実際のクライアントで安心して使うために重要なのが、堅牢性テストスイートです。同じドキュメントへの 40 件の同時書き込み、悪意のあるパス、極端に大きなページサイズ、ラテン文字以外の名前をテストします。MPXJ のオブジェクトモデルはスレッドセーフではなく、MCP クライアントは呼び出しを自由にパイプライン化できます。保護なしでは、60 件の同時書き込みがすべて失敗し、ドキュメントが使用不能になりました。現在は各ドキュメントに独自のロックがあり、複数のツールが互いを利用する構成に対応できるよう、ロックは再入可能です。

スケジュールは閉じるまでメモリ上に保持され、170 MB のスケジュールでは約 400 MB のメモリを消費します。多数のスケジュールを読み込むと、保存されていない変更がない最も古いドキュメントが破棄されます。開いているすべてのドキュメントに未保存の変更がある場合は、それらを破棄するのではなく、新しいドキュメントを開く操作が拒否されます。project_health では、開いているドキュメントと、それぞれのメモリ消費量を確認できます。

インストール可能なパッケージを再ビルドするには、dotnet pack -c Release を実行してください。

---

フォーマット

読み取り .mpp .mpt .mpx MSPDI .xml · Primavera .xer .pmxml · Asta .pp · Planner · GanttProject など。MPXJ を使用します。

書き込み MSPDI .xml（Microsoft Project でネイティブに開けます） · .mpx · Primavera .xer および .pmxml · Planner · SDEF · JSON · CSV · Power BI データセット · Microsoft Project がインストールされている場合はネイティブ .mpp。

ディレクトリ構成

src/HorizunMsProjectMcp/
  Diagnostics/   COM detection and the environment doctor
  Backends/      MPXJ I/O, the COM bridge, sessions and fingerprints
  Analysis/      critical-path engine, working calendar, DCMA-14, earned value
  Writes/        the verified-write engine
  Bim/           element matching and the 4D bridge
  Tools/         the 27 MCP tools
tools/
  acceptance-test.py   end-to-end across all tools, 65 checks
  scheduler-test.py    engine correctness, format round trips, safety guards, 45 checks
  planning-test.py     recovery, sequencing, target dates, learning, generation, 52 checks
  robustness-test.py   concurrency, malformed input, resource limits, 34 checks
  smoke-test.py        environment and capability matrix, 15 checks
  packaging-test.py    versions, identifiers and client manifests agree, 33 checks
  imported-file-test.py   a schedule Microsoft Project saved: ids, outline, custom fields, capacity, 16 checks
  planner-features-test.py  calendars, costs, outline, scenarios, S-curve, read-only safety, 32 checks
  project-engine-test.py  Microsoft Project as the engine, against Project by hand, 29 checks

設計の根拠と、そのきっかけとなった市場ベンチマークについては、DESIGN-TOOL-SURFACE.md と BENCHMARK-MCP-MSPROJECT.md を参照してください。

指示の仕方を学ぶ

Horizun Hubでは、実際の建設・設計業務でAIエージェントに指示を出す方法と、成果物に署名する前に内容を確認する方法をスペイン語で学べます。このMCP向けのコースは、Opera agentes en Microsoft Projectです。実際の建設業務を題材にした短い授業と、検証可能な修了証が用意されています。

エージェントを初めて使いますか？Opera agentes de IA desde ceroのレベル1は、アカウントがあれば無料で受講できます。

ライセンス

MIT.