セキュリティ・キャンプY3(探査機自作ゼミ）応募課題を晒す
はじめに
セキュリティ・キャンプ2025に通ったので応募課題を公開します。第１希望の探査機自作ゼミに通って嬉しい。
次年度の人の参考になれば幸いです。
DDD駆動で課題をやったので誤字脱字があったりイキったこと書いてます。ちょうと期末試験と河合塾の採点バイトの選考とサマーインターンの選考締め切りでスケジュールがやばかったんです。
私の応募者番号は428だったんですが合格者の中で最大値なので一番最後にエントリした合格者の説がある
応募課題
Q1
あなたが今までに作ったことのあるものを自由に語ってください。複数人で作った場合は、どの部分をどのように担当したのかを明示してください。それがソフトウェア、もしくはソフトウェアを含むものであれば、どのような言語・ライブラリを使ったかも教えてください。作ったものが公開リポジトリなどにある場合は、そのリンクも書いてもらえるとうれしいです。
大学に入学してから「メモコード」というワンタイムパスワードを使うことで即興で不特定多数にURLなどのメモを共有できるサービスを作っています。バックエンドはnode.jsとexpress、フロントエンドはHTMLとCSSのベタ打ちです（軽量なので）。現在はvercel上でデプロイしています。
高校時代には高校の時間割を配信するLINEBotを開発していました。GoogleAppScriptを使い（記述した言語はJavascript）、GooleDocsから取得した時間割データをLINEWebhookを使ってLINEで送信するというものです。
Github,Qiita,メモコードへのリンクを乗せておきます。まだ開発段階である部分もあるため応募課題を提出してからDDD (Deadline Driven Development)で技術記事と技術ブログは書きます。
sharememo.vercel.app
Q1.1（発展課題）
Q1 で作ったものを作る中であなたが感じた壁のうち、最もあなたにとって難しかったもの、もしくは、特に印象に残っているものを教えてください。あなたはその壁をどう調査し、克服しましたか？具体的に教えてください。壁が克服できなかった場合は、当時どうしたかに加えて、当時は何が不足していたと思われるか、今やり直すならどうするかなどの考えを聞かせてください。
最も大きな壁だったと思うことはプログラミングを「できる」ようになることです。
私にとって一番の壁は、プログラミングスキルの習得の過程の中ににあると思います。私は現在大学１年生ですがプログラミングは高校1年生の頃からProgateなどを使って独学で始めていました。しかし、思うように身につかず、結果として高校時代の制作物であるLINE BotはすべてAIに頼って開発することになってしまいました。
当時の私は、プログラミングを学ぶ際に「すべてを完全に理解しなければ使ってはいけない」と考えていました。しかし、プログラミング言語の仕様やライブラリの構造は非常に複雑で、初心者が完璧に理解してから使うというのは現実的ではありません。
とりあえず全体を学んで、実際に手を動かして調べながら身につけるというスタンスが重要だということに気づき大学入学後「メモコード」という個人開発したサービスはドキュメントを見て試行錯誤しながら作ることができました。完璧な理解を求めるのではなく、「手を動かして使いながら学ぶ」姿勢を身につけたことで大学入学後は新しい技術習得（React、ｃ言語を現在学習中）や積極的な開発につながっています。
Q2
あなたの印象に残っている「これは便利だ」と感じたものを教えてください。工具でも、エディタやその拡張機能のようなソフトウェアでも、5回のクリックを1回にできるショートカットでも、なんでも構いません。また、それはなぜ便利だったのでしょうか？つまり、どのような課題があり、どう解決しているのでしょうか？
Proxmox VE（正確には仮想化環境）
どんな課題があったのか：
従来は、サーバー1台ごとにIPアドレスを調べてSSH接続し、コマンドラインで操作していました。さらに、OSのインストールやバックアップには、ISOイメージをUSBに焼いて物理的に接続し、ディスプレイもつなぐ必要があるなど、手間と時間がかかっていました。
どう解決したのか：
Proxmox VEでは、これらの作業がすべてGUIで行えるようになり、リモートからVMの作成・操作・監視・バックアップが簡単にできるようになりました。これにより、物理的な接続や作業が大幅に削減され、自宅サーバーの運用が格段に効率化されました。
なぜ便利だと感じたのか：
自宅サーバーの管理、運用が楽になったからだと思います。また、Proxmox限定の機能ではないですが「サーバーを仮想化する」という発想自体が自分にとっては画期的で、これまでの面倒な作業が一気に効率化されるだけではなく、マシンの利用効率と保守性も上がったのですごく便利です。
複数台のサーバー管理を一元的に行える、電源管理やストレージの操作がGUI上でまとめて行える、対応する仮想マシン（VM）の種類が豊富、物理サーバーに直接アクセスせずにリモートで柔軟に運用できる、OSSで無料（最重要）というのも理由です。
Q2.1（発展課題）
どのようにすれば、そのような便利なものを自分で開発できるでしょうか？考えてみましょう。もし既に自分が作った便利なものがあれば、そのエピソードも教えてください．
まず何より大事なのは、「不便だ」と感じるものを探すことだと思います。日々の作業の中で「面倒だ」「もっと楽にできないか」と思った瞬間を見逃さないことが、便利なものを生み出す出発点になります。
次に、他の技術や仕組みと組み合わせる発想が重要ではないでしょうか。たとえば、既存のものを組み合わせるだけで、「足し算」どころか「掛け算」的に機能を強化できる場合があります。
つまり、「1 × 1」が「1以上」になるという感覚です。０から新しいものを作る必要は基本無くて1つ1つは既存のものでも、組み合わせることで新しい便利さを生み出せるという考え方です。
自分の作ったと言えるかはわかりませんがPCのキーボード設定は工夫をしています。私のマシンはThinkPadのJISキーボードなのですが変換と無変換にはそれぞれ日本語と半角英数字、かなひらがなキーにはBackSpace、半角全角キーにはAlt＋Tab（アプリ切り替えのショートカット）を割り当て、ThinkPadについているトラックポイントと組み合わせることでホームポジションから指を動かさずにコーディングができるようにしています。Vimも便利なのですがこの設定をすることでブラウジングや他のアプリでもホームポジションから動かさなくて良いので便利だと感じています。これはTrackPoint＋キー割当＋アプリ切り替えショートカットのようにすでにあるものを組み合わせているので事例の一つと言えるのではないでしょうか。
Q3
一般的な単色のボールペンを用意してください。ゼブラ JJ15 のような、シンプルかつ外装が透明で中の構造が確認しやすいものが望ましいです。用意しましたか？それでは、このカチカチとペン先を出し入れする機構のことを考えながら、できるところまで分解してみましょう（元に戻せる自信が無ければ、他人のボールペンではやらないように注意！）。分解したら、各パーツをよく見て、この機構の仕組みを図を交えて解説してください。ペンは発明しているもののこのカチカチ機構はまだ存在していない世界の人にこのアイデアを伝えることを考えてみてください。追伸：ぜひ何度か組み上げたり分解したりしてみてほしいのですが、最後は元に戻すようにしてください。
カチカチ機構とはボタンを押すという１種類動作だけでペンの軸先を出したり引っ込めたりできる機構です。使うメリットとしてはキャップ式と比較してノックするだけで書ける書けないを切り替えることができるという点が挙げられます。キャップ式は使うたびにキャップのつけ外しが必要でキャップをなくす事もあって不便です。実際にJJ15を買ってきて観察しながら紙に仕組みの解説を書きましたので写真を添付します。
Q4
宇宙開発においては、「枯れた技術」と形容されるような、比較的古めの技術が使われることが多いです。特に情報技術においては一般的なIT業界と比較して10年、20年程度の開きがあることも珍しくありません。例えば、C89 や XML が幅を効かせていることはよくあり、PIC・SHマイコン、PowerPC、SPARC も現役で使われていることはしばしばあります。これはなぜでしょうか？そして、この方針にはどのようなメリット・デメリットがあるでしょうか？ ソフトウェア以外とソフトウェアの両方の面について、それぞれ論じてください。
宇宙開発において「枯れた技術」と呼ばれる比較的古めのソフトウェアとハードウェアが利用される理由は、最新技術を使用する計画を立てても計画の実行時にはすでに最新技術ではなくなっている可能性が高いからであると考えます。
まず、宇宙開発には数年ないし数十年の長期的なスパンでの計画と開発、運用が必要です。仮に最新の技術を使って開発したとしても実際に稼働するときにはすでに何年も遅れた技術になっており、さらには致命的な欠陥がその技術から後々発見されるという可能性もあります。であるならば、わざわざ最新の技術を取り入れようとするのではなく、信頼のあるかれた技術を使うことにメリットが有ると考えられます。信頼のある技術のほうが稟議が通りやすいという組織であるが故に避けられない問題もあるように感じました。逆にデメリットとしては古い技術ゆえの使いにくさ、使いこなせる技術者の不足（長期的にメンテナンスが難しくなる）といった点が挙げられるのではないでしょうか。つまり結果的に枯れた技術を利用しているのであって誰かが望んだわけではないということです。他には保守的な考えから採択されたという理由もあると思います。
宇宙開発とIT企業の開発の技術選択に差が生じる理由について考えたのでソフトウェアとハードウェアのそれぞれの面からメリットとデメリットを考えていきます。
ソフトウェア面：
枯れた技術を使うメリットとして、長年にわたって使われてきたことにより、重大なバグがすでに出尽くしている可能性が高いことと、豊富なマニュアルや先行事例が存在するため、トラブル発生時にも対応しやすいという点があります。
一方で、世間一般に使われない故に精通した技術者が少ないという課題があります。また、開発効率や保守性の面では、最新の開発環境と比べて劣ることがデメリットとして挙げられます。
ハードウェア面：
宇宙は放射線が飛び交う過酷な環境であるため、ハードウェアには高い信頼性と耐性が求められます。最新の微細化されたICは、放射線の影響で誤動作（ビット反転など）を起こしやすいため、信頼性の高い旧式のチップが有利です。古めのハードウェアはすでに宇宙環境での十分な実績と検証があり、動作の確実性が保証されている点が大きなメリットです。
ただし、旧式であるがゆえにインターフェースが古く、現代的なデバイスとの接続に制限があり、性能面では最新のハードウェアに比べて処理能力や消費電力効率が劣るというデメリットもあります。メーカーからの供給が止まる可能性があるという問題もあります。
Q4.1（発展課題）
ちなみに、講師の sksat はかなり新しいエコシステムである Rust を実際に仕事の衛星開発で使っており、講義でも Rust を使用する予定です。つまり、前述の「枯れた技術」に対して、少なくともソフトウェア開発の観点ではある種否定的な立場なわけです。これに意見があれば自由に述べてください。ヒント：意見は賛成でも反対でも「それでは足りない」のようなものでも構いません。sksat と意見が異なっても減点するようなことはありません。意見がすれ違うのは当然のことです。ぜひ語り合いましょう！
意見：「それでは足りない」
RustやCは、どちらも多くあるプログラミング言語の中の一手段に過ぎません。したがって、使用する言語や技術は、目的と状況に応じて選択すべきです。それぞれにメリットとデメリットがあり、「枯れた技術」か「最新技術」かという二元論ではなく、適材適所で使うほうが良いのではないでしょうか。
実例として、SpaceXは比較的新しい技術や開発手法を積極的に採用し、急成長を遂げたことで知られています。これは、民間企業だからこそ利益を追求し柔軟に技術選定ができた側面もあるかもしれません。一方で、JAXAのような公的機関では、実績や、稟議の通しやすさといった技術ではなく経営(政治)的な要因が優先されやすく、その結果として“枯れた技術”の採用に偏ることもあると思います。これらの事例での技術選定において言えることは、枯れた技術も、最新技術も、どちらか一方を常に優先すべきではなく、技術選定の本質は「それを使うことにどういう意味があるか」という目的志向にあるべきです。
先生がRustを使って開発を行っているのは、明確な目的と効果を見据えたうえでの選択であり、非常に理にかなった取り組みだと思います。目的を踏まえた技術選定であれば、「新しい技術を使うこと」は最良の手段になります。
要するに、「枯れた技術」か「新しい技術」かという視点ではなく、その技術が本当に目的の達成に貢献するかどうかを、選定の軸にするべきだと私は考えます。
Q5
宇宙機はロケットという輸送手段で地上から宇宙に輸送され、軌道にデプロイされます。一度デプロイされた宇宙機は、原則として物理的に修理することができません。なぜなら、宇宙に出張に行って機体に近づいて蓋を開けることがほとんど不可能だからです。そこに行って蓋を開けられないということは、ノートPCを持っていってデバッガをアタッチし、ソフトウェアを書き換えることもできません。この性質は「非修理系」と呼ばれています。これは非常に不便な特性です。打ち上げて運用を開始してからバグが見つかったらどうしましょう？そのバグは姿勢制御系の秘孔を突いて高速回転を発生させ、遠心力で機体が破壊されてしまうような致命的なものかもしれません。また、バグでなくとも、途中から要求が変わるかもしれません。例えば気象目的の人工衛星で、特定の種類の雲を衛星上で認識するミッションがあるとします。これは問題なく動作していたのですが、運用開始後に別の種類の雲を衛星画像から判定するアルゴリズムが新たに開発されました。これを即座に軌道上の衛星に組み込めると非常に価値があります。このような問題に対して、どのような技術的解決が考えられるでしょうか？また、どのように宇宙機やそのソフトウェア、送信するコマンド群などの運用計画を設計しておけば、運用時に後から発生する問題に対して対処しやすくなるでしょうか？自由に提案してみてください。ヒント：漠然としていて考えにくい場合は、宇宙機を普通のLinuxサーバだと仮定してみるとよいでしょう。ただし、物理筐体を直接操作することはできず、通信機会が1回数分で1日に1回程度の不便なサーバです。インターネットにも繋がっていません。このような制限は適宜調べたり、想像してみたりしてください。
宇宙機は地上から技術的解決としてアップデートを冗長化できるようにするべきだと思います。アップデート中にOSが落ちたり、通信が遮断された場合、不可逆的な故障の（空飛ぶ文鎮になる）リスクがあります。これは避けたいので最低でも2台のマシンを用意し、通常時はマシンAで制御、マシンBをアップデート → アップデート成功時にはマシンBを起動（制御担当を切り替える） or アップデート失敗時にはマシンBをマシンAと同じ状態にする（アプデ前に戻す）という仕組みを導入するとソフトウェアの修正または改善がかなりしやすくなると思います。もともと冗長化のために宇宙機にはコンピューターが複数台搭載されている事が多いので有効活用とも言えるのではないでしょうか。宇宙機と同じ環境を仮想化もしくは物理的なマシンを地上に用意することでアップデートに問題がないかを何重にもチェックしてからアップデートしていますがこのようなアップデートをしやすい本番環境があればさらにリスクを減らす事ができるのではないでしょうか。
私は自宅サーバーでも、無停止での保守性を重視しており、Pi-hole など重要なサービスが動作している環境では、ライブマイグレーションを活用することでアップデート時の障害リスクを最小限にしています。その経験からも、「アップデートの失敗を恐れずに試せる」設計は、長期運用で非常に重要だと実感しています。宇宙環境でCephのような分散ストレージを導入するリスクとマシンAとマシンBを切り替えるマシンの冗長化が必要になるといった問題については私の知識では解答できません。
また、発想としては、軌道上の宇宙機にLLM（大規模言語モデル）を組み込み、プロンプトのみで自動修繕するという夢のようなアイデアも浮かびました。しかし現時点では、予期しない挙動や誤作動のリスクも高く、「枯れた技術」とはほど遠いため、宇宙機のようなミッションクリティカルなシステムでは現実的ではないと考えています。
Q6
このゼミで自作する探査機で探査してみたいものや、やってみたいことを自由に述べてください。実現可能性などはさておいて、ブレインストーミング的に自由にアイデアを書いてみてください。余裕があれば、それを実現するための手立てをできるだけ具体的に考えてみてください。
Q5でも触れた冗長化（アップデートを2マシンで切り替えて行う、電源をわざと突然切るなど。RaspberryPiに過酷な目に敢えて遭わせる）
=>2マシン組み込むのは先生の設計した基板とRaspberryPiという構成だと厳しいかもしれない。SDカードを増設できれば可能かも？電源をわざと落とすは実現できそう。システムが立ち上がらないときのフェイルセーフ設計とかはできるかも
通信の突然遮断
=>突然遮断したとき復帰できるかを見る。どうして私は探査機をいじめる案ばかり思いつくのだろうか。母機の通信を一時的にオフにするだけで実現できる。
探査機を複数台作って中継機として機能させる。（より遠くまで子機で探索できるようにする）
=>実装が難しいかも？時間が足りるかどうか。中継に限らずネットワークにするというのも面白そう。ラズピコにWifiついている必要がある。中継機役、探索役のように役割を分けたほうが実装しやすい。部品も少なくできる。
ラジオとかBluetoothでビーコンを作って複数台の探査機子機で三辺測量を行い位置を特定する
=>遭難したor動けなくなった探索機に物資を運んだりデータだけ取ったりするみたいな設定が作れたら面白い。正確な位置を測定しないと救助とかできないから。ビーコンを用意できるのか。距離をある程度正確に測る事ができる必要があるし、ある程度広い場所が必要。探査機が2台だと考えられる点が2点存在してしまうから最低でも3台用意する必要がある。
おわりに
自信がなくても応募するのは無料なので応募したほうがいいと思います。正直に言うと私自身通るとは思っていませんでした。
セキュリティ・キャンプの参加者の平均年齢は17.5歳らしいです。B1でも平均以上なことに驚きを隠せないです。
Discussion