こんにちは、アークエッジ・スペースの榎田（xenolay）です。Web 系企業の出身で、2025年9月に入社しました。職務の半分くらいは衛星管制システムの開発（の中でも Web 系っぽいところ）を、もう半分くらいは AE2a という人工衛星の運用をやっています。少しキャッチーに言えば、人工衛星の運用をやっている Web 屋（元 Web 屋？）さんです、と言えるでしょう。
……え？Web 屋が人工衛星の運用なんてできるのかもわからないし、それ以前にそもそも「人工衛星の運用」がナニモノなのかイメージがつかない、ですって？
大変よくわかります。かくいう私自身、入社時点でまさにこのような疑問を持っていた一人です。
この記事は、特にソフトウェア領域のエンジニアの方々に向けてこれまでの AE2a の運用の軌跡をご紹介することで、「人工衛星の運用」にイメージを持っていただくことを目的とします。上掲したような疑問が少しでも解消されると良いなと思っています。
AE2a と「衛星運用」の概要
AE2a は、2025年6月24日に打ち上げられた超小型衛星です1。この衛星には複数のカメラが搭載されています。これらのカメラを使って宇宙から地上を撮影し、そのデータを地上に転送することが目的の一つです。
打ち上げ直後から今日に至るまでの1年弱の期間にわたり、衛星管制システムの開発メンバーを中心としたチームによる運用を続けています。
この AE2a は、「低軌道」と呼ばれる軌道にあり、地上から見ると地球の周囲を高速に周回するような見え方をします。したがって、地上にアンテナを用意したからと言っていつでも衛星と通信できるわけではありません2。アークエッジ・スペースの衛星管制システムでは、衛星が地上のアンテナを含めた地上設備（地上局）と通信可能な時間枠のことを「パス」、パス中に実際に行う地上局と衛星との通信を「コンタクト」とよんでいます。AE2a のパスは1日に数回、1回に10分程度です。
今の AE2a の「運用」とは、この「コンタクト」において何をするかの意思決定を行うことである、と言えます。この意思決定を行う人のことをスーパーバイザー（SuperVisor, 以下 SV と書きます）と言います。AE2a の SV はチーム内から1名が担当する形であり、1週間単位での当番制としています。
SV が意思決定を行うため、あるいは SV の意思決定をサポートするために、具体的にどのようなことをするのか、については、1年弱の時間の中で多くの変化がありました。以下では、その変化の一部について述べていきます。
AE2a 運用の変遷
最初期：運用体制の立ち上げ
SV が 1週間で担当するコンタクトは複数個あります。これらのコンタクトを管理する何かしらの方法が必要となります。
AE2a においては、運用初期からコンタクトごとに GitHub Issue を発行しており、コンタクトに関する連絡は GitHub Issue 上の description ならびにコメントによって行っています。また、必ずしも1コンタクトで完結しないトピックについても GitHub Issue を立て、それらの状況を管理する GitHub Projects を用意したうえで、1週間に1回のミーティングで当該 GitHub Projects を主に確認しながら直近の運用やミッションの達成状況、気付きなどを振り返っています。
この枠組みは、Web エンジニアとして経験してきたソフトウェア開発の流れと似ていると思います。私自身、入社後1ヶ月以内に SV を担当しましたが、大きな違和感や問題もなく参入できたと思います（自分が SV をやる最初のコンタクトはさすがに緊張しましたが）。また、私よりも後に新規で SV を担当しはじめたメンバーも大きな困難なく SV 業務に取り組んでいます。
最初は細かな作業に手間取るところも多かったですが（例えば、コンタクトの時間にテレメトリを確認するダッシュボードを開いておく、とか）、運用を継続する中で日々の作業には慣れてきました。他方で、以下に代表されるような課題がありました。
- コンタクトの予約・承認・干渉調整が自動化されておらず、人力での作業が必要
- 運用スクリプトの作成やテレメトリ確認について、定型的な内容でも高い認知負荷が要求され、たびたび内容にミスが発生したり確認に時間を要したりする
- 複数コンタクトにまたがって状態を管理する仕組みが乏しく、SV自身がその状態をがんばって記憶しないといけない
これらの課題は、共通する重要な特徴を有しています。それは、運用する衛星の機数が増えるに従って負担が増していく、という点です。例えば、スクリプトの作成や送信、テレメトリの確認を人手に頼り続けている場合、これらの作業の負担は運用する衛星の機数に対して線形に増え続けます。
このような負担増加に対して人手を増やすことで解決を図るのは、スケールメリットが発生しないため、当社の目指すところとは異なります。当社は複数ミッションについて多数の衛星からなるコンステレーションの構築を目指しています。その目標を達成するには、機数が増えてもスケールする仕組みを整えることが重要です。
自動化・無人化の促進
先程述べたような課題群がこれまで社内でどのように取り組まれてきたか、それぞれ簡単にご紹介します。
コンタクト調整の自動化
アークエッジ・スペースでは日本国内に2つの地上局を有していますが、現在運用している自社衛星は8機あり、軌道上の位置が近いものも複数あります。 同時刻に同一の地上局で複数衛星のコンタクトを行うことは出来ないため、軌道上の位置が近い衛星同士で地上局の取り合いが発生し、いずれかの衛星にコンタクトを諦めてもらう必要があります。このようなコンタクト間の干渉調整を、かつては人手で行っていました。
しかし、この図に示すように、衛星の機数が増えるにしたがって干渉の数が大幅に増加しており、人手で調整する難易度が上がり続けていました。そこで、衛星の干渉調整を自動で行うツールを作成しました3。現在はそのツールによる承認が行われており、上掲したような人手での干渉調整は必要なくなっています。
当該ツールに搭載されているアルゴリズムは現状シンプルなもので、
- 基本的には、各衛星間でなるだけコンタクトの合計時間の割当が平等になるようにする
- 特定の衛星のコンタクトを優先させることもできる
という範囲に留まっています。これは、ツール作成時に社内にヒアリングをしながら考えた際に、いきなり数理最適化の知識を適用するよりも、まずシンプルに自動化の基盤を整えることに注力すべきだと判断したことによるものです。 今後衛星の機数がより増加し、コンタクトのスケジューリングに対する要求が高度化していけば、この部分のアルゴリズムも更に高度なものに差し替えていくのがよいだろうと考えています。
コンタクト前後の作業の自動化
以前に当社小林の記事にて紹介したように、当社の衛星運用においては独自のDSLを用いています。このDSLに対しては型検査がなされるため、コマンド名の間違い等は事前に検出が可能です。しかしながら、型システム上では検出が難しいけれども「不適切な」コマンドを書いてしまう場合は依然としてありました。一例を挙げると以下のようなものです。
- コンタクトの仰角や地理的制約に応じて呼び出すべきコマンドを適切に取り替える必要があるが、そのことを忘れてしまう
- 時刻指定が必要なコマンドについて、指定すべき時刻を間違える
このようなミスが発生すると運用機会が無駄になってしまうため、可能な限り避けたいところです。また、ミスをしないように気をつけながらスクリプトを組み上げるのは単純に神経を使いますし、機数分のスクリプトの作成が必要となると、衛星の機数増加に対して運用がスケールしません。
この点については複数のアプローチで改善を試みていますが、その中の一つとして、他のプログラミング言語を書かせるのと同様に、スクリプトを AI エージェントに書かせる取り組みを試行しています。スクリプトに関するドメイン知識を文章の形でまとめた上で Devin に Knowledge として渡して、運用項目を書いた GitHub Issue のリンクを Devin に伝えてスクリプトを書いてもらうようにしています。この取り組みを取り入れた結果、人手がかかる箇所は運用項目の指示と生成されたスクリプトのレビューのみとなりました。
また、衛星内には多数のテレメトリがあり、その全てを人手で確認するのは人間の認知負荷の限界を大きく越えます。他方で、運用項目が達成できたかどうかは衛星のテレメトリから判断可能です。であれば、その判断をする仕組みを作ったうえで、人間にとって読みやすいレポートの形でまとめて GitHub Issue のコメントに投稿してあげる仕組みがあれば良いです。現在、このテレメトリ確認を行う Claude Skill が定義されており、GitHub 上のコメントから呼び出せるような仕組みになっています。
コンタクト横断での状況管理
本記事冒頭でも述べたように、AE2a はミッション部にカメラを搭載しています。あるコンタクトにおいて撮影の予約を実施し、撮影が実施された後のコンタクトにおいて地上側で撮影データの受信（ダウンリンク、DLとも言います）を行う、というのが典型的な運用項目のひとつです。
つまりこのカメラ撮影とデータ受信には、複数のコンタクトにまたがっての運用を必要とします。また、このカメラ撮影に限らず、衛星の内部状態に応じた運用が必要になったり、タスク間の依存関係を管理する必要がある、という状況はよくあります。
運用初期は、このような複数コンタクトを要する運用項目について、SV の注意力/記憶力に多くを依存している状況でした。コンタクトごとには GitHub Issue が作成されているものの、GitHub の機能だけでは運用項目のステータスを管理するのが煩雑で、複数の Issue の内容を横断して確認する必要がありました。 結果として、SV 業務を引き継ぐ際に「で、何がどこまで進んでいて、結局次週の SV は何からやればいいんだっけ？」という認知負荷が高くなりやすい状況にありました。私自身、SV 以外の開発業務も担当する中で SV 業務とのコンテキストスイッチが大きく、苦労した記憶があります。このやり方を続けた場合、1機で苦労しているのですから、複数機によるコンステレーション運用が困難であることは想像に難くありません。
この問題に対応すべく、ごく最近、運用項目の進行状況を管理するための試験的な Web アプリケーションを社内で動かし始めました。SV 自身やミッション機器の担当者を含めた社内での意見収集・より良い体制の模索を行っている最中です。
この Web アプリケーションの構築にあたっては AWS アカウントの用意から本番デプロイまでを主に2人で行い、実働約1週間程度で完了しています。自由度とスピード感をもって運用の改善に取り組んでいます。
さいごに
ここまで、AE2a の運用でやること、ならびに AE2a の運用でやることがどのように変化してきたか、についてご紹介してきました。これらは、いずれも人手の作業や注意力を要する部分をエンジニアリングによって減らす取り組みであり、入社時点で宇宙特有のドメイン知識がなくとも、他業界で培った経験は活きる、宇宙業界の外での経験と相通ずるものがあると感じます。
何か完成した手順を踏むことに留まるのではなく、手順そのものに対して日々様々な改善を行うことまで射程に含めて、衛星運用に日々取り組んでいます。衛星運用、ならびに衛星運用を支える地上システムを含め、当社の活動にご興味を持っていただけた方は是非以下よりご応募ください！
