Zenn
📌

セキュリティ・キャンプ2025全国大会 Y3 探査機自作ゼミ 応募課題晒し

に公開
seccamp
idea

来年以降、探査機自作ゼミがあるかもしれないことなどを考慮し、いくつかの部分で（省略）をしています。また、（補足） は応募課題に書いてはいないが、あとから知ったもの等を追加で補足するものです。

Q1

あなたが今までに作ったことのあるものを自由に語ってください。複数人で作った場合は、どの部分をどのように担当したのかを明示してください。それがソフトウェア、もしくはソフトウェアを含むものであれば、どのような言語・ライブラリを使ったかも教えてください。作ったものが公開リポジトリなどにある場合は、そのリンクも書いてもらえるとうれしいです。

（省略）

Q1.1（発展課題）

Q1 で作ったものを作る中であなたが感じた壁のうち、最もあなたにとって難しかったもの、もしくは、特に印象に残っているものを教えてください。あなたはその壁をどう調査し、克服しましたか？具体的に教えてください。壁が克服できなかった場合は、当時どうしたかに加えて、当時は何が不足していたと思われるか、今やり直すならどうするかなどの考えを聞かせてください。

（省略）

Q2

あなたの印象に残っている「これは便利だ」と感じたものを教えてください。工具でも、エディタやその拡張機能のようなソフトウェアでも、5回のクリックを1回にできるショートカットでも、なんでも構いません。
また、それはなぜ便利だったのでしょうか？つまり、どのような課題があり、どう解決しているのでしょうか？

これは便利だと感じたものは、LLMと検索の組み合わせです。従来の調べ方を大きく変えました。以前は、たとえば「宇宙開発に使われている技術」を知りたいと思ったとき、検索ワードを工夫して情報を少しずつ集め、それらを自分で組み合わせて全体像を構築するという手間が必要でした。この過程には時間がかかるだけでなく、情報の質や信頼性のばらつきにも注意が必要で、本質的な理解に至らないことも少なくありませんでした。

この課題に対して、LLMと検索を組み合わせて使うことで、大量の関連情報をLLMが整理・要約し、全体像を素早く把握できるようになりました。これにより、従来は多くの時間を要していた「全体の構造をつかむ」というプロセスが効率化され、その分、理解を深めることや次の行動に時間を充てられるようになりました。また、LLMの提示する内容から専門的な用語を拾い、それを起点にさらに深く調べるというアプローチもできるようになりました。

単なる情報収集のスピード向上にとどまらず、LLMとの対話を通して自分の考えを整理したり、アイデアの実現可能性を探ったりできるようになったことで、「知る」ことが終着点ではなく、「知ったうえでどう動くか」を考える時間が圧倒的に増えました。従来の検索だけでは得られなかった思考の深まりや広がりを実感できるようになった点が、非常に画期的で便利だと感じた理由です。

Q2.1（発展課題）

どのようにすれば、そのような便利なものを自分で開発できるでしょうか？考えてみましょう。
もし既に自分が作った便利なものがあれば、そのエピソードも教えてください

（省略：普段どんなことを考えているか、何が大切だと思うかを述べて、自分が作った便利なものを紹介して、実際に友達などに使ってもらってどうだったかを書きました。）

Q3

一般的な単色のボールペンを用意してください。ゼブラ JJ15 のような、シンプルかつ外装が透明で中の構造が確認しやすいものが望ましいです。
用意しましたか？それでは、このカチカチとペン先を出し入れする機構のことを考えながら、できるところまで分解してみましょう（元にせる自信が無ければ、他人のボールペンではやらないように注意！）。
分解したら、各パーツをよく見て、この機構の仕組みを図を交えて解説してください。ペンは発明しているもののこのカチカチ機構はまだ存在していない世界の人にこのアイデアを伝えることを考えてみてください。
追伸：ぜひ何度か組み上げたり分解したりしてみてほしいのですが、最後は元に戻すようにしてください

分解パート

ゼブラ JJ15を準備する。

中央部分を回して、下部のグリップ（黒色のゴム部分）と上部の透明部分に分けます。

そうすると、中からインク部分・バネが出てきます。

上部の透明部分には、まだボールペンを使う際に実際に押す部分（黒色の部品）と白色の部品があるので、それを取り出します。黒色の部品を上から押すことで取り出せます。


これでカチカチ機構に関係する部分全ての分解ができました

この機構の仕組み

指で押す黒色の部品と中にある白色の部品を実際は円柱形ですが断面的に図に示します。赤は押す黒色の部品、青は黒の部品に力を受けて中で動く白色の部品です。図ではわかりやすくするために長方形を斜めにスライスされた図形で表されていますが、厳密にはネクタイ型をしています。また本来は円柱形なので、薄赤色で塗られている部分が押した時に力を加えることができる領域です。

黒色の部品↓
黒色の部品

本来の黒色の部品↓
本来の黒色の部品

①：ペン先がしまわれている状態
②：ペン先が出る瞬間（カチッと押す瞬間）
③：ペン先が完全に出ている状態
④：ペン先をしまう瞬間（カチッと押す瞬間）

①から④を繰り返すことでペン先の出し入れがおこなわれます。
1

2

3

4

このカチカチ機構のポイントは黒部品とペン先にあるバネだと思います。黒部品を押してペン先を出そうとすると下に力を加えることになりますが、バネによって上方向にも反発する力を受けています。黒部品を押して②の図のプラスティックの引っ掛かりを白部品が超えるときに黒部品のネクタイ型の斜面によって左側の方向に回され、プラスティックの斜面に沿って収納されます（②、③）。また、カチッという音は、白部品が引っかかりを超えて黒部品によって回される時に引っ掛かりと白部品が擦れた音であると推測しました。このとき下からの力がないと白部品を押し戻せません。

Q4

宇宙開発においては、「枯れた技術」と形容されるような、比較的古めの技術が使われることが多いです。特に情報技術においては一般的なIT業界と比較して10年、20年程度の開きがあることも珍しくありません。例えば、C89 や XML が幅を効かせていることはよくあり、PIC・SHマイコン、PowerPC、SPARC も現役で使われていることはしばしばあります。
これはなぜでしょうか？そして、この方針にはどのようなメリット・デメリットがあるでしょうか？ ソフトウェア以外とソフトウェアの両方の面について、それぞれ論じてください。

まず、ソフトウェア以外とソフトウェアの両面のメリット・デメリットを挙げ、なぜ現在も枯れた技術が使われているのかを考える。

ソフトウェア以外（ハードウェア）

宇宙空間は高エネルギーの放射線環境にさらされており、これにより電子部品が異常動作を引き起こすSEE（Single Event Effects）やTID（Total Ionizing Dose）などの問題が発生します[2][4]。耐放射線性（Rad-Hard）を持つプロセッサやデバイスが求められます。そのため既に宇宙空間での使用実績があり、信頼性が高いため、長年にわたって継続的に採用されてきました。たとえば、JAXAのSEEDS衛星ではPICマイコンが「放射線耐性に非常に優れたマイコン」として採用されています[3]。

さらに、宇宙ミッションは計画から打ち上げ、運用終了までに10年以上かかる場合もあり、長期的な部品供給やメンテナンス性が極めて重要です。古い技術は長期供給プログラムの対象となっていることが多く[5][6]、供給終了リスクが低いことは大きな利点です。また、開発ツールやテスト手法、デバッグノウハウが十分に蓄積されており、技術者の教育や引き継ぎの面でも優れています。

一方で、デメリットは性能の限界と処理能力の不足です。NASAの資料によれば、2000年前半の段階で商業用と耐放射線性のコンピュータの性能は約7倍で10年以上の技術ギャップが存在するとされています[7]。

ソフトウェア

ソフトウェアにおいても、古い技術が使われる主な理由は運用実績と安定性です。たとえば、C89は1989年から仕様がほとんど変わっておらず、標準規格として広く認知され、長期的な安定運用が可能です。これは、長期運用を前提とする宇宙ミッションに適しています。また既存のコーディング・デバッグのノウハウが豊富に蓄積されており、sksat先生のブログで指摘されているように「（積み上がったノウハウを）盲目的に信仰するなということ」[9]はさておき、長期にわたって運用されてきた実績があります。

しかし、開発体験が極めて悪いというのは大きな欠点です。Rustの rustup target add や Cargo のような体験は得られません。他にもC言語では（省略）。
さらに、セグメンテーションフォールトやコアダンプのような抽象度の低いエラー情報しか得られないため、基本的にはデバッガでアタッチすると思いますが、それ以前にどこでエラーが起きたのかはキャッチするべきだと思います。（省略）

以上より、宇宙開発において「枯れた技術」が使われ続けている理由は、主に信頼性・安定性・長期運用性にあります。これまでは国家規模のプロジェクトであることが多く、民間のプロジェクトが増えた今でもさまざまなプレッシャーのもと、宇宙開発が行われています。そのためハードウェアでは放射線耐性や長期供給、ソフトウェアではノウハウと安定性がその選定を後押しして既に実績のある技術が選ばれやすくなっています。一方で、技術の進化の恩恵を受けにくくなり、性能の制約やセキュリティ・開発体験の低さといった問題も生じます。

参考文献

特に指定がない場合、閲覧日は2025年06月09日です。

  1. JAXA 宇宙航空技術コラム「宇宙用部品の放射線対策」, https://www.aero.jaxa.jp/spsite/rensai/column/45.html
  2. 文部科学省「委託業務成果報告書(新宇宙産業を創出するスマート宇宙機器・システムの研究開発拠点 2年目)3」, https://www.mext.go.jp/content/20240820-mxt_uchukai01-000019567_70.pdf
  3. 日本大学理工学部航空宇宙工学科「SEEDS」, https://stage.tksc.jaxa.jp/taurus/member/miyazaki/old/sat_SEEDS.html
  4. Reconfigurable Scalable Computing for Space Applications (PDF, p.3, 5, 24), NASA, https://nepp.nasa.gov/DocUploads/DFAD416F-9552-4251-A791D500AD4FF9F8/RSC-Overview-GSFC.pdf
  5. BAESystems「製品およびサービス」, https://www.baesystems.com/ja-jp/
  6. ルネサンス「長期製品供給プログラム」, https://www.renesas.com/ja/support/product-longevity-program-plp
  7. Reconfigurable Scalable Computing for Space Applications (PDF, p.26, 28), NASA, https://nepp.nasa.gov/DocUploads/DFAD416F-9552-4251-A791D500AD4FF9F8/RSC-Overview-GSFC.pdf
  8. XML SPECIFICATION FOR NAVIGATION DATA MESSAGES, NASA, https://www.nasa.gov/wp-content/uploads/2017/12/ccsds_xml_specifications_for_navigation_data_messages.pdf
  9. ArkEdge Space で正社員になって半年が経った, sksat, https://sksat.hatenablog.com/entry/2023/02/02/031716
  10. （省略）
  11. （省略）

Q4.1（発展課題）

ちなみに、講師の sksat はかなり新しいエコシステムである Rust を実際に仕事の衛星開発で使っており、講義でも Rust を使用する予定です。つまり、前述の「枯れた技術」に対して、少なくともソフトウェア開発の観点ではある種否定的な立場なわけです。これに意見があれば自由に述べてください。

ヒント：意見は賛成でも反対でも「それでは足りない」のようなものでも構いません。sksat と意見が異なっても減点するようなことはありません。意見がすれ違うのは当然のことです。ぜひ語り合いましょう！

C言語の資産をFFIを用いて活用したり、あるいは必要に応じてフルスクラッチでRustに移行していく方針には、概ね賛成です。単に「新しいから」という理由でRustを導入するのではなく、たとえばAeroRustのようなコミュニティを形成し、知見の共有やノウハウの蓄積を推進していく姿勢は、非常に重要だと思います。また、sksat先生がご自身のブログで述べられていたような開発体験の向上という観点ももちろん重要ですが、Q4で述べたとおり未知のバグや予期せぬ動作のリスクを、言語レベルで最小限に抑えられるという観点もあります。

ただし、こうしたモダンな技術への移行を一律に推し進めるべきかというと、一部ではそうとも言い切れないと思います。たとえば、1961年の人類初の宇宙飛行以降、半世紀以上にわたり改良・活用され続けてきたハードウェア・ソフトウェア資産を一律に「古い」として切り捨ててしまうことには慎重であるべきです。歴史的に蓄積されてきた技術や経験には、それ自体に大きな価値があり、どこまでを移行し、どこを保持するかという判断は、個別のミッション要件や安全性、信頼性、コストなどを勘案した上で行うべきだと思います。したがって、私はモダンな技術を積極的に取り入れる姿勢には賛成しつつも、新旧の技術を適切に取捨選択し、共存させていくことが、今後の宇宙開発において必要あると考えています。

Q5

宇宙機はロケットという輸送手段で地上から宇宙に輸送され、軌道にデプロイされます。一度デプロイされた宇宙機は、原則として物理的に修理することができません。なぜなら、宇宙に出張に行って機体に近づいて蓋を開けることがほとんど不可能だからです。そこに行って蓋を開けられないということは、ノートPCを持っていってデバッガをアタッチし、ソフトウェアを書き換えることもできません。この性質は「非修理系」と呼ばれています。

これは非常に不便な特性です。打ち上げて運用を開始してからバグが見つかったらどうしましょう？そのバグは姿勢制御系の秘孔を突いて高速回転を発生させ、遠心力で機体が破壊されてしまうような致命的なものかもしれません。

また、バグでなくとも、途中から要求が変わるかもしれません。例えば気象目的の人工衛星で、特定の種類の雲を衛星上で認識するミッションがあるとします。これは問題なく動作していたのですが、運用開始後に別の種類の雲を衛星画像から判定するアルゴリズムが新たに開発されました。これを即座に軌道上の衛星に組み込めると非常に価値があります。

このような問題に対して、どのような技術的解決が考えられるでしょうか？また、どのように宇宙機やそのソフトウェア、送信するコマンド群などの運用計画を設計しておけば、運用時に後から発生する問題に対して対処しやすくなるでしょうか？自由に提案してみてください。

ヒント：漠然としていて考えにくい場合は、宇宙機を普通のLinuxサーバだと仮定してみるとよい。ただし、物理筐体を直接操作することはできず、通信機会が1回数分で1日に1回程度の不便なサーバです。インターネットにも繋がっていません。このような制限は適宜調べたり、想像してみたりしてください。

宇宙機は一度軌道上にデプロイされると、原則として物理的に修理することが不可能なため、打ち上げ前にバグを極限まで排除する手法と、打ち上げ後の要求変更や障害に柔軟に対応するための運用設計の両面から、十分な技術的対策が必要です。本回答ではまず打ち上げ前に可能な技術的施策を述べ、その後に運用設計およびバグ発生時の対処について提案します。コストに関しては今回は考慮せず、技術的可能性を重視して議論を行います。

なお、打ち上げ後の通信に関しては、NASAのDeep Space Network（DSN）やJAXAの開発するDTN技術[1]により、送信したデータが宇宙機に確実に届く前提で話を進めます。

打ち上げ後に物理的アクセスができないという制約上、打ち上げ前の段階でソフトウェアの正当性と堅牢性を確保することは極めて重要です。ここでは以下の2つの技術を有効な手段として挙げます。

  • ファジング（Fuzzing）
    異常入力によってソフトウェアのバグを見つけるテスト手法で、特にCOTS（Commercial Off-The-Shelf）部品やオープンソースライブラリの利用が増える近年の宇宙機開発においては、既知・未知の脆弱性を発見するうえで有効ではないかと考えました。

（補足：A Case Study on Fuzzing Satellite Firmware）

  • 形式検証（Formal Verification）

    ソフトウェアやプロトコルの性質を数学的に検証する形式手法は、特に非修理系においてシステム仕様と実装との整合性を保証し、致命的バグの混入を防いだり、運用前に高い保証性を得たりするのに有効ではないかと考えました。

次に運用中にミッション要求が変化することを想定する場合の技術的対策を述べます。宇宙機の機能をモジュール化・スクリプト化しておくことが有効ではないかと考えました。
（省略）
このような思想は「Software Defined Satellite（SDS）」という概念として整理されつつあるようです[2]。

最後に打ち上げて運用を開始してからバグが見つかった場合の技術的対策を述べます。パッチやアップデート情報を送らないといけないわけですが、無線で情報を送るOver-the-Air(OTA)があります。宇宙空間では実際に、NASAの火星探索機「キュリオシティ」は制御ソフトウェアのアップデートを軌道上で実施した例があります[3]。パッチやアップデート情報も同様に送ることができればバグを修正することが可能ではないかと考えました。ただ、更新情報が第三者によって改竄・傍受されるリスクを考慮し、通信内容の暗号化および署名検証による認証機構を宇宙機側に実装する必要があると思います。

また、致命的な不具合によるシステム障害に備え、安全モードへの遷移機能や冗長構成も必要です。例えば、センサ情報（回転・温度等）を常時監視し、異常検知時には問題のあるモジュールを無効化して代替機能に切り替える仕組みが挙げられます。実際に、JAXAの探査機「はやぶさ」では、イオンエンジンを三基搭載し、一基を予備として使用する冗長構成が採用されていた例があります[4]。

参考文献

  1. 追跡技術開発チーム　研究開発員 森永優, 「DTNの研究開発 宇宙通信の劇的な進化に立ち会う」, JAXA 衛星利用運用センター, https://track.sfo.jaxa.jp/soraoibito/morinaga.html
  2. 「宇宙技術戦略（衛星・分野共通技術）の方向性」, 内閣府宇宙開発戦略推進事務局, https://www8.cao.go.jp/space/comittee/27-anpo/anpo-dai59/siryou1.pdf
  3. "第191回　携帯電話から火星探査機まで、最新のソフトウェアを提供する仕組み", TDK テクノロジー・マガジン, https://www.tdk.com/ja/tech-mag/knowledge/191
  4. 國中均, 『希望を現実にした「はやぶさ」のエンジン』, JAXA, https://www.jaxa.jp/article/special/hayabusareturn/kuninaka01_j.html

Q6

このゼミで自作する探査機で探査してみたいものや、やってみたいことを自由に述べてください。
実現可能性などはさておいて、ブレインストーミング的に自由にアイデアを書いてみてください。
余裕があれば、それを実現するための手立てをできるだけ具体的に考えてみてください。

ブレインストーミングでさまざまな状況やそれに対するアイデアを出した中で、自作する探査機でやってみたいことは、転倒や身動きが取れなくなった際の自己修復です。私は探査機が動き続けることが面白いと思いますし重要だと思うのでそれに焦点を当てます。
（省略）
自己修復機能を持たせたいです。

Discussion