UNISEC外第22-22号

超小型衛星ミッションアッシュアランス・ハンドブック
Ver 2.0

2023年3月
特定非営利活動法人大学宇宙工学コンソーシアム(UNISEC)

1

改訂履歴VersionVer.1
Ver.2.0

改訂日時2022 年 3 月
2023 年 3 月

改訂内容
第１版として発行(UNISEC 外第 21-21 号)
UNISEC アカデミー、UNISEC Global 等ででたコメントを反映
第 2 版として発行(UNISEC 外第 22-22 号)

2

大学・高専発超小型衛星の Mission Assurance Handbook
目次
1. はじめに
2. プロジェクトマネージメント
2.1 スケジュール管理2.2 チーム体制
2.3 効率化
2.4 周波数調整・電波免許
2.5 安全要求への適合
2.6 文書管理
2.7 不具合管理
2.8 外部ステークホルダとの関係
2.9 資金計画
3. ミッション定義
3.1 実現性
3.2 サクセスクライテリア
3.3 ミッションシナリオ
3.4 リスク管理
4. 概念設計
4.1 要求管理（ミッション要求、設計要求、検証要求の整合性）
4.2 過去のプロジェクトの教訓の反映
4.3 安全要求適合性確認
4.4 検証計画
5. 詳細設計
5.1 部品・コンポーネント選択
5.2 リスク管理、FTA、FMEA
5.3 死なない衛星を心がける
5.4 過剰な保護機能を避ける
5.5 設計変更時の留意点
5.6 運用しやすい衛星設計
5.7 試験しやすい、製造しやすい衛星設計
5.8 設計根拠の理解
5.9 FM に移行する前に5.10 安全要求適合性確認
6. 製作
6.1 品質管理
6.2 作業外注と内製
6.3 安全要求適合性確認
7. 試験
7.1 電磁適合性試験
7.2 End-to-End ミッション試験
7.3 電気的インタフェース（噛み合わせ）試験
7.4 システム機能試験
7.5 End-to-End 長期運用試験

3

7.6 展開試験
7.7 フィットチェック
7.8 熱試験
7.9 振動試験
7.10 試験コンフィギュレーション（Test-as-you-Fly）
7.11 外部試験機関の利用
7.12 試験結果の評価
7.13 不具合対応
7.14 衛星の保管
7.15 安全要求適合性の確認
8. 運用
8.1 地上系準備・メンテナンス
8.2 運用計画
8.3 不具合対応
9. 運用後
9.1 Lessons Learned
9.2 記録化と成果報告・公開
9.3 ノウハウ共有
10. 大学衛星プログラムの持続可能化
10.1 プログラムとしての視点
10.2 学内基盤の強化
10.3 資金確保
10.4 外部連携

4

略語
AIT
AT
BBM
CDR
C&DH
EM
FM
FET
FMEA
FTA
ISS
MA
MDR
MCU
MOSFET
OBC
PDR
QT
Rx
Tx

Assembly, Integration and Testing
Acceptance Test
Bread Board Model
Critical Design Review
Command and Data HandlingEngineering Model
Flight Model
Field Effect Transistor
Fault Mode Effect Analysis
Fault Tree Analysis
International Space Station
Mission Assurance
Mission Definition Review
Micro-Controller Unit
Metal-Oxide-Semiconductor Field Effect Transistor
OnBoard Computer
Preliminary Design Review
Qualification Test
ReceiverTransmitter51. はじめに本文書は大学・高専等（以下、簡単化のため「大学」とする）が開発する超小型衛星の Mission 成功率を向上させるために、教員・学生を含む開発・運用チームが念頭におくべき事項をまとめたものである。ミッション保証（Mission Assurance）とはミッションの成功を阻害する設計・製造・運用等における要因を見つけ、その影響を軽減させる一連の活動を意味する。
本文書の適用対象は「超小型衛星」であるが、 衛星のサイズや重さでその範囲を定義するのではなく、 “Lean Satellite”（衛星がもたらす価値を安く・早くにユーザ
ー・顧客・ステークホルダに届けるために従来の衛星とは異なるリスク許容型の開発・マネージメント手法をとる衛星[1]）として適用対象を捉えるべきである。リスクを許容するがために、個々の衛星は失敗するかもしれないが、次の衛星を速やかに打ち上げることで衛星プログラムとしての価値を安く・早く届けられるようにする。そのために、衛星のサイズや重さが小さなものとなっている。CubeSat を含む所謂「超小型 衛 星 」 ・ 「 小 型 衛 星 」 ( 英 語 で は pico-satellite, nano-satellite, microsatellite 等々)の多くが Lean Satellite の範疇に収まり、大学衛星は 100％当てはまるといえる。本文書では、日本語で馴染みのある「超小型衛星」を使うこととする。
大学で衛星が作られるようになって 20 年以上が経過し、超小型衛星は今や単なる学生の教育ツールとしてだけではなく、最先端の科学観測やビジネスにも使われるようになっている。いわゆる「New Space」と呼ばれる多くの新興企業が大学衛星プロジェ
クトを経験した元学生達によって立ち上げられ、躍動する宇宙セクターの原動力ともなっている。
日本においても、これまでに 20 を超える大学が超小型衛星を打ち上げているが、そのミッション成功率は未だ低いままである。世界的に見てもそれは同じであり、文献[2]によれば、大学発衛星の 25%が DOA(Dead-on-Arrival、軌道上放出後に地上局で電波を一回も受信できない）に終わっており、ミッション成功と分類される衛星は「部分的な成功」を含めても 50%に満たない。
大学衛星のミッションは「教育」「技術実証」「科学観測」が主たるものである。
しかし、たとえ「教育」をメインミッションとしていたとしても、運用によって得られる教育的効果は開発段階で得られる教育的効果に匹敵する。そのため、教育衛星といえども、地上との間で電波をやりとりして衛星に何らかの仕事をさせる、すなわち軌道上で何らかのデータを取得してダウンリンクすることを目指さなければいけない
大学衛星のミッション成功率を向上させることは、卒業後に宇宙セクターに進む人
材の教育効果を上げるだけでなく、大学衛星を活用した挑戦的な「技術実証」「科学観測」の成果を向上させることにもつながる。それらの成果は、より大きな規模で行われるミッションのパスファインダーとして活用され、宇宙セクター全体の発展に寄与することとなる。
本文書は、2020 年度に大学宇宙工学コンソーシアム(UNISEC)が行った Lessons
Learned 共有会において出されたさまざまなミッション成功・失敗事例を分析したものが基となっている。Lessons Learned 共有会のまとめは文献[3]として出版済みである。
文献[3]の 5.2 章に「超小型衛星のミッションアシュアランスのための要件項目の抽出」
として、超小型衛星ミッションを成功させる上で必要な要件項目を抽出している。本文書は、失敗事例の Root Cause Analysis をさらに行なった結果に基づいて、それら要件項目を衛星のシステムライフサイクルに沿う形で加筆・修正・再構成し、衛星プ
ロジェクトに関わる教員・学生が衛星プロジェクトをやりながら常に参照できるようにした。特に6

プロジェクトの実施形態に応じた大学における適切なマネージメント方法
プロジェクトを「効率良く」実現するポイント
ミッション定義から運用後に至るまでのプロジェクトライフサイクルの各フェー
ズ毎にミッション成功率向上のために実施すべき事項● 個々の単発のプロジェクトではなくプログラムとしてミッション成功率を確実に向上させていくために、大学衛星プログラムを持続的に行っていくためのポイン
トの４点を念頭においている。
大学衛星のミッション成功率は、初号機では極めて低く、2 号機以降は自らの教訓を反映することで大きく向上する。しかしながら、2 号機以降でも失敗がなくなるわけではない。自分達以外の多くの衛星プロジェクトと経験知を共有することで、ミッショ
ン成功率をさらに向上させることができる。そのため、本文書の対象は、初めて衛星開発に携わる教員・学生だけでなく、2 号機以降に携わる大学関係者も含んでいる。
本文書は、特定非営利活動法人大学宇宙工学コンソーシアム(UNISEC)が国立研究開
発法人 宇宙航空研究開発機構（JAXA）から受託して実施した業務 「2021 年度 超小型衛星の成功率向上に向けた JAXA 知見を活用した支援方法の調査検討」（JX－PSPC－
536920A）の一環として作成されたものである
●
●
●

7

2. プロジェクトマネージメント
2.1 スケジュール管理
大学衛星の場合、初号機からミッションに成功することは稀である。失敗原因の多
くは、経験不足からくるスケジュールの読み間違いが、最終的なシステム全体を使っての試験時間の不足につながったことにある[3]。相乗りに頼る大学衛星では、衛星納入日を自ら選べることは少ない。そこで衛星納入日を D として、スケジュール管理の目安となるマイルストーンを表１に示す。(A)〜(E)までに示された期間を短縮することは厳しい。物品の発注・調達にかかる時間は学生の頑張りだけでは短縮できない。
また(A)と(B)で全系を組み合わせてどれくらい長い期間動作させて、どれだけのハード・ソフトの欠陥を検出し修正できるかが、衛星の軌道上生存率やミッション成功率を左右する。そのため(A)や(B)の時間を縮めてスケジュールの遅れに対処しようという考えは持つべきではない。
表１

スケジュール管理の目安

時期
D
(A)
D-1 月

マイルストーン
衛星納入
ソフトウェアのバグ出し（１ヶ月）
FM ハードウェア・ソフトウェアが完成し、ハードウェアに関する試験（振動・熱真空等）を終えている。
基本的な地上局ソフトウェアが完成している。
(B)
FM 組み立て・統合・試験（2 ヶ月）
D-3 月
FM に使用する各種ハードウェアが納入され、組み立てを待っている。
(C)
FM 発注・調達（３ヶ月）
D-6 月
EM の試験が完了し、衛星システムとして動作することが確認されている。
(D)EM 組み立て・統合・試験（４ヶ月）
D-10 月 EM に使用する各種ハードウェアが納入され、組み立てを待っている。
(E)
EM 発注・調達（３ヶ月）
D-13 月 想定したミッションが実施可能である確証を得る。
EM の設計が完了し、発注が始まる。
(F)
Proof of Concept
D-A*月
どのようなミッションを実施するかが決まる* 時期は衛星プロジェクトにより異なる(A)の期間中（１ヶ月）は、ハードウェアの変更は基本的に行わず、End-to-End 長期運用試験（7.5 を参照）でソフトウェアのバグ出しに専念する。ただし、ソフトウ
ェアにバグが見つかったとしても、FM のソフトを実際に変更するかどうかは、変更によるリスク（それまで動いていた部分が動かなくなる）と変更しなかった場合のリスク（軌道上でバグが発生する）を比較した上で慎重に判断すべきである。
(B)の期間中（2 ヶ月）に FM の組み立て•統合・環境試験(AIT)を行う。AIT 中に不適合が見つかり、FM の改修が必要となる場合が多く、２ヶ月は必要である。試験日程が刻々と変わる可能性があるので、試験実施場所が外部機関の場合は、当該機関との連絡を常にとっておく。
(C)の期間中（３ヶ月）に FM の発注・調達を行うが、EM 試験結果に基づく FM での設計の軽微な変更が必ずある。図面の引き直しなどで予想外の時間を要する場合がある。

8

この間に FM の試験日程を組み、試験設備を確保しておくべきである。その際、FM の組
み立て・統合に時間を要することを考え、FM 試験日程は少なくとも Plan-A(予定通り進んだ場合)と Plan-B（予定通り進まなかった場合）の２通りを想定しておく。
(D)の期間中（4 ヶ月）に EM の組み立て・統合・試験を行う。組み立て・統合はコン
ポーネントが全て揃ってから一度に行うのではなく、納入された物品から順にインタ
フェース適合性を確認していくべきである。組み立て時に機械インタフェースの不適合が数多く見つかるので、構造系や基板の改修が必要となる。統合時には電気的イン
タフェースの不適合が数多く見つかり、トラブルシューティングに多大な時間を要する。振動や熱真空といった環境試験は慣れていないため、スケジュールに余裕をもっておく。特に初号機の場合、EM 振動試験は 1 回で終わらない場合が多いので、複数回することを覚悟しておく。通常は(D)の期間の最後に CDR がある。
(E)の期間中（3 ヶ月）は EM の納入を待つ期間であるが、その間も安全審査対応のための構造解析や STM 振動試験、BBM を使ってのソフトウェア開発等々、やることは多くある。また EM の試験日程を組み、試験設備を確保しておく。
(F)の期間中（長さはプロジェクト毎に異なる）に BBM 等のハードウェアを使って、ミッションが実施可能であることを確かめておく(PoC, Proof of Concept の実施)。複数のミッションを搭載する場合、PoC の結果が芳しくないものについては、搭載を断念する決断が必要となる。決断を後回しにするだけ、EM や FM の設計変更につながる恐れが増え、コスト増・スケジュール遅延につながる。メインミッションの場合、PoC の結果に応じてミッション要求を見直すべきである。通常は(F)の期間の最初に MDR、最後に PDR がある。
2.2 チーム体制
大学において、衛星のプロジェクトチームを編成する際、学生だけでは必要なタレントが全て揃うことはない。足りないところは、スタッフを雇用する、学生の成長に期待する、外部機関と連携する、買い物で済ませる、といった解決策があるが、いずれも確実ではなく、ミッションの難易度や予算や地理的状況などなどを考慮してベス
トな策を得る必要がある。いずれにせよ、衛星ミッションの策定を行なっていく上で、チーム内のタレントの見極めが極めて大事である。参考のために、表２に見極め作業で使えるようなチェックリストを示す。このチェックリストは体制の優劣を決めるものではないが、チームの経験、学生のスキルレベル、専門分野の多様性等々を俯瞰す
るのに使える。

9

表2

衛星プロジェクトのタレントの見極めのためのチェックリスト

項目

回答選択肢

責任教員(P/I)が講義の時間以 100

50~99

20~49

5~19 0~4

3 以上

2

1

0

3 人以上

2

1

0

3

2

1

0

機械

電気 通信 メカト 情報

外に衛星プロジェクトに費やせる時間(%)
責任教員の衛星プロジェクトの経験
衛星プロジェクトに関与する
教員（学科プロパー）
衛星プロジェクトに専念する
スタッフの数教員の専門分野（複数）宇宙工学 理学ロ
プロジェクトマネージャー

他

責任教員 (P/I)以外 専任ス 博士 修士 学部生 学部生(P/I)のプロパ タッフ 学生 学生 （研究 （研究ー教員

プロジェクトマネージャーが

その

3 以上

2

室内） 室外）10

機械

電気 通信 メカト 情報

経験した衛星プロジェクトの数
参加学生の学科（複数）

宇宙工学 理学ロ
学生の学年(複数)

博士

修士

その
他

学部 4 学部 学部
年

3年

1~2
年

責任教員の研究室外の学生の

推奨

限定的

100

50~99

20~49

0~19 0

3 以上

2

1

0

参加
衛星プロジェクトを経験した
学生の割合(%)
衛星プロジェクトに主体的に関与する外部機関の数

チーム内のタレントが把握できたとして、衛星ミッションを実施する上でチーム内では解決できない専門知識やノウハウを効率的に得られる仕組みを作ることが重要である。ここで注意すべきは、外部にコンポーネントの開発や製作について協力を要請したとしても、その仕様はミッション要求やシステム要求と合致していなければならず、仕様をチームメンバー（特にプロマネや当該コンポーネントを使用するサブシス
テム担当者）が理解している必要がある点である。またコンポーネントが納入されたとしても、システムに組み込んで衛星全体の検証を行うのは大学側の責任であり、チームメンバーがそのことを肝に銘じておく必要がある。
大学衛星プロジェクトは、たとえ専任のスタッフを雇ったとしても、学生の献身的な労働なしには成り立たない。学生のプロジェクトへの参加は、学生個々に異なるモ
チベーションによって支えられている。そのモチベーションの維持・向上の責任は全て教員にあることを、教員は肝に命じるべきである。衛星プロジェクトに対するモチ10

ベーションは学生個々人で差があるのは当然である。モチベーションの低い学生が重要なタスクを割り振られたがために、プロジェクト全体が進まなくこともある。そのような場合は早めの対策が必要であるが、その際にプロマネの役割は極めて大事である。教員とプロマネの間で常にコミュニケーションをとり、問題の特定と解決に努めるべきである。
研究室プロジェクトの場合、学生の卒論・修論・D 論とリンクさせることができるが、そうでない場合は学生にプロジェクトに参加する意義を見出させる必要がある。特に少人数・短期集中開発は学生も精神的に追い込まれる。ゴールの先に得られるものを学生が明確に意識できるようにしなければならない。
サークル活動の場合、学生の出入りは基本的に自由であり、学部低学年であることも多く、教員と学生のつながりも研究室プロジェクトほどには太くない。普通の部活
動と異なり、対外試合があるわけでもなく、コンテストのように数ヶ月先に明確なゴールが見えているわけでもない。教員側が積極的に関与する姿勢を見せ、学生の懸念を早期に拾い上げる努力をしなければ、学生間のつながりだけでモチベーションを維持するのは難しい。
学生のモチベーションを維持する上で、打ち上げが決まっていることが何よりも重要であり、打ち上げの決まらない学生衛星プロジェクトは漂流することになる。ただし、打ち上げが決まれば信頼性のある衛星を学生が作るわけではなく、教員が常に「打上げ日までに衛星を間に合わせるのが成功ではなく、打ち上げ後に予定していたミッションを実施できて初めて成功と言える」ということを言い続けることが必要である。教員が「ミッション成功が大事」と言い続けなければ、学生はついてこない。
また、衛星の開発期間があまりに長すぎると、学生は衛星プロジェクトの一部しか経験できず、モチベーションを持たせることが難しい。開発から運用までの一連のプロセスをすべて体験できることがモチベーションにつながる。そのためには、プロジェ
クト立ち上げから運用までを 3 年以内に実施することが望ましい。
3 年というプロジェクトのライフサイクルの設定は非常に大事である。軌道上で開発
時に見過ごしていた問題が発覚した場合、運用で回復するしかない。できることは限られているものの、衛星の設計を熟知していることにより、とりうる対策の幅は広がり、時には絶望的な状態から回復することもありうる。大学衛星プロジェクトの実施
形態は工学系の研究室を中心に行われる「研究室型」のものが多いが、学生は学部４年生から修士２年生までの 3 年間在籍するケースが多い。プロジェクト立ち上げから打ち上げまで 3 年以上を要すると、運用時には衛星の設計に精通した学生がいないということが起こり得る。多額の外部資金を獲得してきて、専任スタッフや大学院生（修士・博士）が多数参加する「研究指向型」のプロジェクトでは、専任スタッフの雇用の際に、開発完了まででスタッフの雇用期間を区切るのではなく、運用も見据えた雇用期間とすべきである。研究室外の学生も参加する「サークル型」は３年を超えたライフサイクルも可能ではある。ただし、あまりにもプロジェクトが長期化すると学生のモチベーション維持が難しい。また、研究室配属後は卒論・修論等があるので、指導教員の理解がない限り４年生以降は多くの時間をプロジェクトに割くことができない。そのため、「サークル型」であっても３年程度でライフサイクルを終わらせる
ことが大事である。
大学衛星では、P/I (Principal Investigator)である責任教員の判断が最優先されるが、重要事項の判断は P/I の教員が一人で行うのでなく、複数の人間で話しあって冷静に議論した上で決めるべきである。教員には、他者の意見を受け入れる度量の広さ11

が求められる。
大学衛星で学生・ポスドク・若手教員がプロマネをする場合、上席教員（通常は P/I）
は状況を常に把握し、必要であれば外部に助けを乞う。学生やポスドクではなかなか
外部とのチャンネルもなく、助けを得難い。そのため、適切なチャンネルを外部との間に作るのも上席教員の役割である。教員は学生やポスドクに丸投げすべきではない。
一旦チャンネルができたあとは事情をよく知る学生やポスドクが直接外部に連絡する方が伝言ゲームにならなくて済む。
システム全体を見渡せるのがプロマネ 1 人である体制は、そのプロマネに事故などがあった時に非常なリスクを抱えている。システム全体に精通した人材を複数用意しておく。また、チーム内でも情報の共有を進めておく。１人の人間に依存したプロジェクトマネージメントは、リスクがあまりにも高く、するべきでない。そのためにも、
平常時からチーム全員が一つの部屋で過ごすような開発体制が望ましい。また、逆にいうと、プロマネ１人でシステム全体を見渡せないようなシステムは超小型衛星とは言い難い。また、システムが複雑になればなるほど、超小型衛星開発の経験者（システムライフサイクルの全てを経験した者）がプロマネになるのが望ましい。
2.3 効率化
文献[4]に倣って、衛星プロジェクトにおける活動を３種類に分類する。1 番目は、衛星の価値を向上させる活動。この中には MA も含まれる。2 番目は、価値は向上させないものの必要な活動。この中には安全審査対応や宇宙活動法・電波免許等に関する作業が含まれる。3 番目は、その他の「ムダ」な活動である。超小型衛星では、この「ムダ」をできる限り減らすことによって、限られた人員と資金で衛星を開発・運用する。
衛星プロジェクトにおいては、「移動」と「待ち」でムダが発生しやすい。そのムダを削減し、得られた余剰の時間を MA に振り分けるべきである。同じキャンパスの中で開発する場合であっても、チームの所在地が分散していると、ミーティングや組み立て・統合・試験作業のために一箇所に集まるための移動時間はムダである。衛星運用においても、地上局までの移動時間はムダである。コロナ禍において遠隔作業やコ
ミュニケーションは大きく進化したが、それでも対面で行う作業やコミュニケーショ
ンに対して効率は大きく劣る。キャンパス内に試験設備がない時、試験実施場所までの衛星の輸送や人員の移動はムダな時間である。メイルによるコミュニケーションは、返信が来るまでの時間は「待ち」であって、価値の向上に繋がらない。チーム全員が同じ部屋に滞在して、細々としたコミュニケーションは口頭で行うことで、時間が大きく節約される。記録として残すべき事項については、テキストメッセージ化するな
どの使い分けをすべきである。移動とコミュニケーションを効率化するには、居室、作業室、試験設備、地上局を同一建屋内に集約することが望ましい。
2.4 周波数調整・電波免許
衛星の開発が順調に進んでいたとしても、周波数調整・電波免許申請の結果、基本設計の変更、ミッションの変更、衛星納入の遅れ、衛星ミッションの断念、衛星運用の制限などに追い込まれることがある。特に、アマチュア無線と非アマチュア無線の併用、一次割り当てでない周波数の使用等については、注意が必要である。また、超小型衛星の数の増加に伴い、アマチュア無線周波数割り当てや予備免許発行にかかる時間が長引く傾向にある。特にアマチュア無線の精神に即しているかどうか判断が難しい衛星はアマチュア無線周波数割り当てが長引いている。周波数調整や予備免許発

12

行が終わっていない衛星は打ち上げることができないため、電波関連の官辺手続きの遅れが衛星納入の遅れ、最悪の場合打ち上げ機会の喪失につながることを認識すべきである。
国際周波数調整並びに無線免許申請は電波法と電波関係の専門知識を必要とするので、特定のメンバーに仕事が集中しがちである。プロマネを始めとする複数のメンバーが周波数調整の進行状況を常にモニタしておく必要がある。また複数のメンバーが文献[5]に目を通しておくことが望まれる。周波数調整作業を外部コンサルタントに依頼することも厭わない姿勢をもつことが重要である。また、外部コンサルタントに依頼したとしても、プロジェクト側の人間が状況を常にモニタしておかなければいけな
いのは当然である。
2.5 安全要求への適合
安全要求への不適合は設計見直しや製作やり直しにつながり、それらに費やす時間が MA 活動に費やす時間を圧迫することになる。また安全審査を通らない衛星は打ち上げることができないので、最悪の場合は打ち上げに間に合わずダミーマス搭載という事態になりうる。実際に、そのような事例が過去にいくつか起きている(図１)。安全要求不適合による出戻りを少しでも減らすため、概念設計、詳細設計が終わったそれ
ぞれの段階で安全要求適合性に関わる課題を抽出し、打ち上げ事業者に確認をとっておくべきである。
安全審査においては、どのような方法で安全要求への適合性を検証するかが問われるが、最小限のエフォートで検証できる手法を打ち上げ事業者との間で合意すべきである。過剰な約束（大学教員は見栄をはって過剰な約束をしがちである）をすると、あとで自らを苦しめることになりかねない。安全要求への適合性の検証は必要最小限のエフォートにとどめ、MA 活動等にリソースを割り振るべきである。
システム安全の責任者は、設計や AIT の担当者に対して時に強い意見を言わなければいけない。安全要求の背後にある技術的理由を理解し、各担当者に噛み砕いて説明できる資質を備えた人材を充てるのが望ましい。

図 1 H-IIA 30 号機に搭載された小型副衛星（6 時の方向にある銀色の塊がダミーマ
ス）（写真出典：JAXA デジタルアーカイブス）
https://s3-ap-northeast-1.amazonaws.com/jaxa-jda/http_root/photo/P100010489/5590ac570abed216cfe9acfe71681338.jpg

132.6 文書管理
衛星プロジェクトにおいて、文書が必要となるのは以下のような理由による。
a) 官辺対応（安全審査、周波数調整・電波免許、宇宙活動法）
b) プロジェクト内の意思疎通（開発・試験・運用の際に現場で必要）
c) 運用時の不具合対応に備えたトレーサビリティーの確保
d) 知識伝承e) 他プロジェクトとの知識・ノウハウ共有f) 論文作成時の源泉データ(a)と(b)については、これなしでは衛星が完成し打ち上げることができないので、否応なしに文書化作業をしなければならない。(a)については、教員・スタッフに文書化作業を行う時間的余裕や適性がないのであれば、学生がやるしかない。そのため、プロジェクト発足時に安全審査関連の文書作成を重要タスクの一つとして学生に割り振る。学生にタスクの重要性を理解させた上で、「この仕事の成否によって衛星が打ち上がるかどうかが決まる」といったモチベーションを与える。当然、学生が作成する安全審査関連書類のチェックは教員・スタッフがしないといけない。(b)については、各系の担当やプロマネが必要に迫られて作成するので問題ない。基本的に文書化作業が好きな学生はおらず、また衛星開発と同時平行で作られるので、教員が「勉強のため文書を作れ」と指導しない限り、必要最低限の文書セットが作られることになる。
(f)については、論文執筆を考えている教員・学生（多くは博士学生）が自分で作成、または他の学生を指導して作らせることになる。
MA 活動に関連するものとしては、(b),(c),(d)となる。特に大学内の世代交代により衛星の設計内容を熟知したものが運用時に欠ける状況に備える、次号機プロジェク
トを円滑に進めるといった観点で必要となる。しかし、学生にいくら「知識伝承は大事。文書で残せ」といっても、それで学生は動かない。一つの方策として、衛星プロ
ジェクトを学生の卒業論文・修士論文とリンクさせる案がある。理工系の学生にとって、卒業論文、修士論文は必須である。衛星プロジェクトにおいて、ある系やコンポーネントの開発または試験を卒論・修論のテーマとして実施すると、卒論・修論では否応無しにそれらのことを書かないといけない。体系的な文書作成にはならないが、特定分野においては、非常に詳細な設計文書ができあがることになる。例えば、アンテナ展開機構を学生の卒論とした場合、学生は、アンテナの基礎から、どのようにしてテグスを結び、どのような試験条件でどれだけ試験をおこない、その成功率はいくらであったか、失敗したとしたらその要因等々、自分のやった事項について非常に詳
細な記録を残すことになる。
2.7 不具合管理
衛星の開発作業(AIT も当然含む)中には必ず不具合が発生する。それらの不具合への対処を怠らないよう、プロマネまたは担当者に不具合情報を集約し、抜けがないような取り組みが必要である。このような取り組みは衛星が複雑になればなるほど大事である。不具合管理表を採用して管理していくことの有効性がいくつかの衛星で示されている。ただし、様々な不具合に対してミッション達成に対する影響に基づいて優先順位をつけ、リソースを分散させない注意が必要である。また、BBM フェーズなどの開発初期段階では担当者が不具合事象を不具合と見做さず、単に開発作業が終了していないだけと思うこともあり、担当者が途中で変わったりすると不具合がそのまま取り残されたりすることもある。プロマネと担当者の意思疎通が重要である。

14

2.8 外部ステークホルダとの関係
自社の製品を宇宙で実証したい企業からの依頼が大学衛星に来ることが多い。企業側には自社で衛星を作るよりも遥かに手間とコストを省けるといった利点があり、大学側には企業から資金導入できるという利点がある。また製品自体に研究開発要素があった場合、共同研究として学生や教員の論文発表につながる可能性もある。しかしながら、企業側の依頼を受ける際には、インターフェースや仕事の分担を明確に決めておくべきである。システム側（大学側）にとって負担の少ないのは電源ラインとデータラインだけを提供して、実証実験データの測定回路等は全て企業側の責任で作ってもらうことである。少なくとも衛星バスへの影響を最小限にする努力が必要である。
企業側との調整が曖昧なままであると、多大な人的リソースを企業ペイロードのために配分することになったり、プロジェクト最終段階で思わぬ設計変更を強いられたりすることがある。また、資金を得られるからと言って企業からの申し入れに安直にとびつかず、企業をステークホルダとして招くことによって衛星システムが複雑になることや調整の手間が増えることに対して、対処が可能であるかどうかをしっかりと見極めた上で判断すべきである。
2.9 資金計画
衛星プロジェクトにはお金がかかるものである。特に初号機においてはどれくらいのお金がかかるかを予想するのは非常に難しい。地上局やクリーンブースなどの最低限のインフラ整備にも資金が必要である。能動的姿勢制御をせず、UHF 帯の通信機しか搭載しない 1U CubeSat を開発しようとした場合、EM と FM のハードウェアにかかるコストは合計で 1000 万円程度かかると覚悟しておいた方が無難である。外国製の CubeSat
プラットホームを購入するとさらに金額はあがり、EM と FM 合わせて 1000 万円を切ることは難しい。これに地上局やクリーンブースなどのインフラや、電源や測定器などの試験用機器を加えると 1500 万円程度に経費が膨らむ。これらに学外での試験費用や旅費等を加えると、初号機の場合、打ち上げ費用を除いて 2000 万円程度用意しておくのが望ましい。２号機以降は、インフラ等のコストがなくなり、前号機の余剰部品の使用や経費削減のノウハウの蓄積により、プロジェクトあたりのコストは当然下がってくる。資金が足りなくなったからと言って学生の自作に頼ると、信頼度の低下やス
ケジュール遅延につながりかねない。また、資金難を解消するために外部ステークホ
ルダを入れるなどすると、衛星が複雑になって信頼性が低下したり、プロジェクト運営が難しくなったりする懸念もある。資金計画には余裕をもつことが求められる。見切り発車や楽観は危険である。

15

3. ミッション定義
3. 1 実現性
チームの構成員の知見やスキルが衛星の開発・運用に必要なすべての範囲をカバーしていることは、まずあり得ない。新規にスタッフを雇用して足りないタレントを外部から導入するという考えも、必要となる人材を確保できる保証はない。学生の成長に期待しすぎるのも危険である。また、予算も限られている。ミッションを策定する
場合には、そのような制約条件を強く意識すべきである。用意できる予算と人員で実施可能な「身の丈にあったミッション」を策定すべきである。また、教育目的の衛星においては、新規開発の要素が多すぎるとプロジェクトが破綻する危険性があることに留意すべきである。
大学衛星は教員次第である。教員が背伸びをしても、学生がついてこれないことがある。また、教員は神ではないので、ミッションの実現性を評価する上で全てを知っているわけではない。自分の足りないところを率直に認め、外部の助けを請う、自分の不得意なところで無理をしない、といったことが重要である。外部に助けを請う時
は、経験者のコメントを真摯に受け止める姿勢が大事であるが、その前提としてコメントの良し悪しを判断できるだけの力量が必要であり、それらを身につける努力を怠るべきではない。
3.2 サクセスクライテリア
サクセスクライテリアは、プロジェクトを進めていく上での指針である。通常はミニマムサクセス（システムに何らかの不具合があったとしても、これだけは何があっても達成できる最低限の目標）、フルサクセス（システムが要求通りに機能した場合に達成できる成果の目標）、エクストラサクセス（フルサクセスを達成した上で、さらにそれを上回る成果の目標）の３つで構成される（文献[6]）。できるだけ定量的な指標（特にミニマムサクセスとフルサクセス）を使うことが求められる。
サクセスクライテリアはプロジェクト立ち上げ時に策定するが、レビュー会などプ
ロジェクトの各節目においてそのクライテリア、特にフルサクセス、を達成できるかどうかをチェックする。達成できないと思われる時は変更せざるを得ないが、それによってプロジェクト全体の意義（プロジェクトのステークホルダを満足させられるかどうか）が達成できるかを問い直すべきである。また設計変更の可能性を検討する時には、設計変更によってもミニマムサクセスクライテリアを達成できるかどうかを真摯に吟味すべきである。安易にミニマムサクセスクライテリアを変更すべきではない。
また、プロジェクトがうまくいきそうだとのことで、各サクセスクライテリアを上方修正することは、システム要求の後付けとなるので、やめておいた方がよい。システ
ム要求の後付けは、プロジェクト失敗をもたらす原因になりやすい。
また、運用時においては、各サクセスクライテリアの達成状況が運用計画を立案する際の指標となる。後述（8.2 運用計画）するように、衛星が軌道上に放出されたら速やかにミニマムサクセスクライテリア達成のための運用を行うべきである。
3.3 ミッションシナリオ
どのようなミッションを実施するかがある程度で揃った時点で、各ミッションの運用シナリオを策定する。地上局からコマンドアップリンクにより衛星がどのように動作し、軌道上からデータをどのようにして地上におろすかを考える。それらにより、衛星が備えるべき機能と大体の性能を算出することができる。その結果に基づいて、必要となる搭載機器を洗いだし、衛星の通信、電力、姿勢（ポインティング）のバジ

16ェット表を作成する。このバジェット表は衛星プロジェクトの進行中に随時改訂を行
い、衛星の開発・製作・検証が進むとともに数字の確度を向上させていく。ミッショ
ン定義の段階で通信、電力、姿勢のバジェットでマージンがない、またはギリギリであれば、そのミッションは成立しないと考えた方がよい。
この段階で、電力バジェットでは、太陽電池回路を一つ失ってもフルミッションサ
クセスが達成できるほどのマージンが最低でも欲しい。通信バジェットでは、ダウンリンクでは、ミニマムサクセスを達成するのに 10dB、フルサクセスを達成するのに6dB 程度のマージンが欲しい。コマンドアップリンクはこの段階では 20dB 程度のマージンが欲しい。

3.4 リスク管理
衛星プロジェクトとは未知（うまくいくかどうかわからない）を既知（うまくいく
ことに自信がある）に変えていく過程でもある。ミッションを実現する上で必要となる技術のうち、未知のものは必ず存在する。存在しないようなプロジェクトは面白くない。その技術が他機関の衛星プロジェクトでは普通に使われていたとしても、自分達のチームで使ったことがなければ、それは「未知」のものである。「未知」のもの
は、全て衛星のミッション達成を阻害するリスク要因である。ミッションシナリオが策定されれば、どのような機能が衛星に必要かがわかるので、「未知」のものをその時点で洗い出すことは可能である。リスクマネージメントにおいては、それら「未知」のものが失敗する可能性、失敗した場合のミッション達成に及ぼす影響度を評価しな
いといけない。開発や検証が進むにつれて「未知」の度合いが「既知」に置き換わり、それが失敗する可能性がある程度朧げに見えてくるはずである。リスクマネージメン
トの結果、失敗の影響度が深刻なものには重点的にその後のリソースを振り分ける必
要がある。

17

4. 概念設計
4.1 要求管理（ミッション要求、設計要求、検証要求の整合性）
衛星のミッション要求と設計に整合性がとれていなければならない。これは衛星の概念設計の際に、複数の人間で冷静に議論をして決定すべきである。外部の専門家・経験者に議論に加わってもらうのもよい。例えば、衛星のミッションが教育に主眼を置いていれば、「確実に動く衛星」を作ることにより運用を経験させることが望まれる。そのような時に、研究開発要素の高いコンポーネント（例えば、全く新たな設計のアンテナ）を採用することは、ミッション要求に反することになる。設計要求は、
上位のミッション要求に適合しなければいけないが、時に大学研究者の「色気」がでてきて、ついついシステム開発の基本を忘れがちである。そのような時は、別メンバ
ーまたは外部からの指摘により、目を覚ます必要がある。責任教員には、他者の意見を受け入れる度量の広さが求められる。
逆に、ミッション要求のレベルが高いのに、それにそぐわない設計を行う場合もある。理論上の最大通信容量を前提として通信回線を設計し、それに基づいてミッションが要求するデータをダウンリンク可能としがちであるが、実際の運用において最大通信容量がでる場合はほとんどない。ダウンリンクできるデータ量は理論上の最大通信容量の 10%を大きく下回ることが殆どである。このような場合も、概念設計の段階で外部からの指摘が役に立つ。
4.2 過去のプロジェクトの教訓の反映
すでにいくつかの衛星プロジェクトを経験している場合、概念設計時に過去のプロジェクトで得られた教訓を反映するのは当然のことである。軌道上で動いたものと、動かなかったものに整理をし、動いたものは非常に良い理由のない限り変更しない。
動かなかったものについては、その原因を究明した上で改良措置を施すことが大事である。外部からコンポーネントを調達する場合、調達のしやすさや、アフターケア等についての経験が得られているはずなので、同じコンポーネントを採用するかどうかを慎重に考慮すべきである。
4.3 安全要求適合性確認
概念設計が終わった段階で、詳細設計に入る前に安全適合性の課題を抽出すべきである。安全審査 Phase0/1 として実施しても良いが、経験のある専門家であれば問題になりそうな箇所を指摘するには概念設計書を一読するだけで足りるので、そのような専門家に設計をレビューしてもらうのも一案である。
また２号機以降のプロジェクトでは、前号機の安全審査担当者から安全に関する事
項（なぜこのような安全要求があって、このような検証をしないといけなかったか）について聞いておくのが良い。
4.4 検証計画
検証とは要求通りの衛星が作られているかどうかを確認する行為であり、試験以外にも解析や図面確認等により行われる。概念設計時に、各設計要求に対して、それらを何時どのように(When and How)検証するかを定めた検証計画を策定する。勿論、設計・開発が進むにつれて計画は変更されていくが、検証できない設計は採用するべきではなく、「多分動く」「大丈夫だろう」という考えは禁物である。また、実施可能な「検証計画」をたてるべきである。「放射線試験で確認する」という検証計画は書
くのは易しいが、試験設備を使用可能か、チーム内に放射線試験のノウハウがあるか、18

等々を考慮しなければならない。放射線試験を実施しないなら、耐放射線設計は、飛行実績のある部品を使う等、放射線試験をしないという前提にたって進めないといけない。
全ての試験設備を自前でもっているところは少なく、外部の試験機関を使用する場合が多い。どこで試験を実施するかについても、概念設計時にある程度のあたりをつけて試験機関と相談を始めることが望ましい。試験に関しての経験が乏しいプロジェ
クトの場合、衛星設計や試験についての助言をできるだけの経験をもった試験機関を選ぶのがよい。
[2.5 安全要求への適合性]でも述べたように、安全要求に対する検証は必須ではあるが、一部（構造破壊の検証など）を除き衛星の価値を向上させるものではなく、その検証に割くエフォートは必要最低限のものとすべきである。衛星の価値を向上させる要求（衛星の生存率を高める、ミッションの成功率を高める、軌道上で得られるデータの質を向上させる等々）の検証により注力すべきである。例えば、バッテリーの安全性の検証は、安全審査でよく問われるところであり、学生は膨大な時間を費やしてバッテリーのスクリーニングを行っている場合が多い。また、実際に作業を行っているので、学生は「やってる感」をもちがちである。確かにバッテリーのスクリーニ
ングは要求されている限りやらなければいけない活動であるが、衛星の価値向上のた
めには他にもっとやらないといけないことがあるということをチームが理解すべきである。ただし、あまりにこれを強調するとバッテリースクリーニングのような地道な活動を行う学生のモチベーションが低下するので注意が必要である。
国際宇宙ステーションから放出される CubeSat の場合、最低限実施すべき試験は表 3の通りである。ここで“R”とある項目は“Required”を意味し、それぞれの段階で実施すべき試験である（なお、“O”は“Optional”、“N”は“Not Required”である)。
それぞれの試験の詳細は 7 章で述べる。解析としては、構造解析（共振周波数、最大許容荷重や安全余裕の算出）が必須である。
H2A やイプシロンなどのロケット打ち上げの場合は、表 3 の項目に加えて準静的荷重試験（所謂サインバースト）や正弦波振動試験、衝撃試験等が課される。
表 3 国際宇宙ステーションから放出される CubeSat において実施すべき試験
試験項目
EM(QT)FM (AT)
電磁適合性試験
R
N*1
End-to-End ミッション試RN*1
験
電気的インタフェース試RR験
システム機能試験
R
R
End-to-End 長期運用試験
N
R
展開試験
R
R
フィットチェック
R
R
熱試験
R
O*3
ランダム振動試験
O*2
R*1: FM 段階では End-to-End 長期運用試験に含まれる*2: 衛星毎に特段の必要があれば実施する。必要がなければ省略して構わない*3: 安全要求への適合検証のために、-15℃と+60℃に晒されたあとでも衛星が動くことを示す必要がある（文献[7]参照）。設計（使用部品の温度範囲等）で検証できなけ

19

れば試験が必要となる。熱真空試験や恒温槽での熱サイクル試験は、衛星毎に特段の必要があれば実施するが、必要がなければ省略して構わない。

20

5. 詳細設計
5.1 部品・コンポーネント選択
コンポーネントの購入先として海外ベンダー（売主、製造業者等を指す）を選択す
る場合は、納期・アフターサービス・インタフェース適合の観点から注意を払う。他のコンポーネントとの間でインタフェース不適合の問題が発生した際のベンダーとの調整に多大な時間を要することを理解すべきである。ただし、国内ベンダーであっても、経験の浅いベンダーの場合は注意を要する。技術力があっても、納期に難のあるベンダーもある。ベンダー選択の際、入手性、取り扱いの用意さ（インタフェースのわかりやすさ）、修理対応の良さなどにより注意を払うべきである。それらは時に、
サイズ・金額・機能を上回る価値をもつ。
部品・コンポーネントの調達数には余裕をもたせておくことが大事である。ハード
ウェアを取り扱う以上、取り扱い不注意や試験時の過負荷による故障や破損は避けられない。スケジュールが非常にタイトな中でぎりぎりの個数でやっていると、故障・破損したとしても代替品を調達する時間がなく、打ち上げ延期に追い込まれる危険がある。EM としてフライト品と同等のものを調達していれば、万が一の際には EM 品を使うことができる。実際のフライトに使われなかったとしても、運用時にコマンドの動
作確認や不具合究明に使う FM 予備機に使用できる。また、コロナ禍以降、半導体をはじめとする各種電子部品の調達が非常に難しくなっており、リスク管理の一環として早めの調達が必要となっている。部品やコンポーネントの到着が衛星納入のぎりぎりになり、システム試験の時間が確保できなくなる事態は避けなければならない。
特に新規開発要素のあるコンポーネントの場合、ベンダーとの間での作業項目のイ
ンタフェース境界をはっきりさせ、どこまでをベンダー側でやり、どこまでをシステ
ム（衛星プロジェクト側）でやるのかを明確にしておくべきである。衛星プロジェク
トをプログラムとして捉え、バス機器については、できるだけ仕様を変えず、2 号機・３号機はコンポーネントベンダー側での開発要素をなくし、同一品を納入してもらう体制が、納期短縮の観点から望ましい。ベンダー側も従業員を動かし原材料を調達して物品を製作する以上、大学衛星だからと言って過度な値引きやアカデミックディスカウント等を期待すべきではない。ベンダー側が損をすることなく、2 号機以降も長期的に付き合っていける関係を構築すべきである。
共同開発であったとしても、最終的にはベンダー側に設計やノウハウを移管し、ベンダー側が責任をもってコンポーネントを供給できる持続可能なサプライチェーン体制を構築することが望まれる。安定した製品品質を維持することを維持するには、長期的な付き合いが可能なベンダーを選択すべきである。
5.2 リスク管理、FTA、FMEA
大学では、「失敗を許されない」衛星を作ることは不可能であり、ミッション失敗のリスクを許容する。しかしながら、リスクがあっても何もしないわけではなく、そのリスクが現実化する可能性（発生確率）と現実化した際の影響（深刻度）を総合的に評価して、限られたリソース（人員・予算・スケジュール等々）の中で優先順位の高いものからリスクの低減化をはかる。通常は、発生確率と深刻度の積が大きいものから優先的にあたる。ただし、注意が必要なのは、発生確率や深刻度を定量的に評価するにはお金や時間がかかるので、超小型衛星の場合はそれらの評価に経験や群衆の叡智(Wisdom of Crowd)が使われる。そのため、リスク評価においては、超小型衛星の開発経験者や専門家にコメントを求めるのが良い。概念設計が固まった段階で外部の専門家にレビューを依頼することで、安全要求適合性の課題とともに、優先すべきリ

21

スク項目についても有益な意見を得ることができる。
技 術 的 な リ ス ク を 洗 い 出 す 作 業 と し て FMEA(Fault Mode Effect Analysis) や
FTA(Fault Tree Analysis)を活用する。しかしながら、FMEA や FTA を大学の講義で学
ぶ学生はほとんどおらず、やり方すらも知らない。責任教員も同様である。そのため、最初から無理をして文献等にある方法をなぞったりしようとはせず、自分達で理解できる範囲から始めることが肝要である。
FTA については、ミッションシナリオをフローチャート化し、それぞれのステップがうまくいかないとすれば、どのようなコンポーネントに責任があるかを考えればよい。
FMEA については、個々のコンポーネントが壊れたらミッション遂行が「(1)問題なく実施できる、(2)制約はあるものの実施できる、(3)ミッションの実施は不可能だが衛星は動く、(4)衛星全損（通信途絶）」（ミッションに与える影響）といった場合分けをする程度から始めることを進める。またコンポーネントが壊れるかどうかについても「(1)飛行実績がある、(2)同様の設計のものに飛行実績がある、(3)飛行実績のあるメーカー（プロ）の設計・製作による、(4)地上環境では間違いなく動く、(5)全くの新規設計、(6)学生の手作り」（故障の起こりやすさ）といった評価指標を使うとわかりやすいかもしれない。いずれにせよ、その部品・コンポーネントが故障すると衛星全損につながる危険性のあるもの（単一故障点）について洗い出し、リスク軽減作業の優先順位を決めることから始めるべきである。単一故障点が複数あって、リソースの制約から全てに対処することが難しいときは、ミッション遂行に与える影響（先に挙げた 1-4 の数字）と故障の起こりやすさ（先にあげた 1-6 の数字）の掛け算の大きい
ものから対処することが望ましい。
また、FTA や FMEA は部品・コンポーネントといったモノについてだけ行うのではな
く、作業についても考えるべきである。「コマンドを打ち間違えたらどうなるか？」「センサーの極性を逆にしてしまったらどうなるか？」等々、人間は間違いをおかす
ものなので、それらの間違いが起きた時の結果を吟味し、間違いが起きにくくする、
間違いが起きても挽回可能にするなどの工夫を設計に反映する。
5.3 死なない衛星を心がける
どのようなことがあっても衛星全損(地上との通信途絶)の危険から抜け出すシステ
ムとしての工夫を設計に盛り込む。例えば以下のような工夫がある。
● 「神 PIC(放射線耐性の高さが軌道上で実証されている PIC16F877)」を搭載し、衛星全体の電力を落として再立ち上げ（パワーリセット）できるようにする● バッテリーが枯渇しても再充電される工夫や低電圧時に確実にセーフモードに移行する仕組み● バッテリーを喪失しても、太陽電池パネルの発電だけで衛星が動作する設計● 体積的に余裕があれば通信回線を冗長にする● 最低限の動作（地上との上下の通信回線が確保でき、バッテリーの大幅な放電を許容すればいくつかのミッションも実施可能）のための電力バジェットが以下のような場合でも成り立つようにする➢ 姿勢の喪失➢ 太陽電池パドルの展開失敗➢ 1U キューブサットの場合、太陽電池パネルの１面喪失（こうしておかないと、４〜６枚ある太陽電池パネルのうちどれか１枚でも喪失すると衛星が失われることになり、単一故障点が太陽電池パネル分（４〜６個）並列にあることになる）

22

ただし、これらの設計を行ったとしても、設計通りにシステムが全損の危険から抜け出せることを検証することが必須である。衛星がパワーリセットから立ち上がる時に、中途半端な状態でシステムが半死の状態に陥ることもある。軌道上での不具合状態を想定した試験を行い、衛星システムがパワーリセットから完全に立ち上がることを確かめるべきである。バッテリーの枯渇状態からの復活は、ソーラーアレイシミュ
レータを使うなどして、軌道上の発電状態を模擬して確かめるべきである。セーフモードへの移行も実機を用いて試験を行うべきである。電力バジェットについても、最悪の電力状態でのシステムの動作を確認するべきである。電力バジェットを立てる際には、発生電力・消費電力ともに測定誤差があるので、ある程度のマージンを考慮すべきである。通信系についても、冗長系の通信試験を怠るべきではない。
5.4 過剰な保護機能を避ける
衛星設計においては、さまざまな保護機能をつけたくなる。例えば、バッテリー枯
渇を防ぐセーフモードや、低温でのバッテリー保護のためのバッテリーヒータである。
しかし、これらを設計に採用する前に、その保護機能が本当に必要か、保護機能を入れることによるリスクと効果を吟味すべきである。保護機能が自動で入るようになっているということは、電圧や温度センサーが正常に機能することを想定しているが、果たしてセンサーがどれだけ信頼できるかを考えるべきである。セーフモードは中途半端な状態に陥って立ち上がらないという危険があり、実際にそのような状態に陥った衛星もある。バッテリーヒータは電力を消費する。それによって電力収支がマイナスとなり、バッテリーが枯渇する可能性がある。
セーフモードを採用せずに、バッテリー電圧が低下したら DC/DC コンバータの入力限界を下回って衛星負荷への電力供給が自動的に遮断され、衛星の電力が一旦全て落とされるパワーリセットがかかり蝕明けに再度衛星が初期モードから立ち上がるような設計にするのも一案である。バッテリーヒータについても、自動でスイッチが入る
ようにはせず、軌道上での温度推移を見ながら地上からのコマンドで起動するような設計にしておくことが望ましい。軌道上でバッテリーが突発的に低温になることはな
い。特に軌道高度が低ければ、衛星全体は高温側にふれるので、バッテリーの断熱を十分にしておけばヒータなしでも十分に運用できる可能性は高い。
5.5 設計変更時の留意点
設計変更においては、常に設計変更によって得られる利益と設計変更によって生まれる新たなリスクを評価した上で、変更の可否を判断しなければいけない。その際の判断指標としてミニマムサクセスとフルサクセスのクライテリアがある。特にミニマ
ムサクセスの達成を阻害するリスクがあった場合は、慎重に判断すべきである。また
設計変更がフルサクセスの可能性を高めるものであった場合、設計変更によって生じるリスクが大きいかどうかを慎重に見極める。例えば、図 2 のように通信回線を多重化するために二つのアンテナと二つの通信機を RF Switch を使ってたすき掛けにするという案があったとする。通信機やアンテナに飛行実績がない場合などは考えがちである。これにより通信機とアンテナの組み合わせが一つは生き残る確率が増え、通信回線全体の信頼度があがるように見えるが、RF Switch を入れることによる電波出力の損失や RF Switch が切り替わらない、または中間状態（通信機とアンテナがつながらない状態）で固定されるというリスクがあり、最悪の場合は通信自体ができない可能性がある。たすき掛けをしなかったとしても通信機とアンテナのペアが一組動けば通信は可能で、少なくともミニマムサクセスクライテリアは達成できる。たすき掛けを23

することで得られる利益がリスクを上回るとは判断されない。

図2

通信機とアンテナの RF Switch を使ったたすき掛けの検討

5.6 運用しやすい衛星設計
どのようにミッションを実施するかをイメージし、2 号機以降であれば過去の運用経験から得られた教訓を最大限盛り込んだ上で、「運用しやすい衛星」を心がけるべきである。初号機の場合は、運用を経験した大学に聞くことも大事である。例えば、ストアードコマンド（予約コマンド）機能は、日本上空以外の地球上の任意の箇所での
衛星ミッションを可能にする。更に、一連の動作をあらかじめ予約しておくことで、
全動作項目の動作を一つずつアップリンクする必要がなくなる。また、ダウンリンク
を別の地上局で実施することも可能になる（ただし、周波数調整時に注意が必要）のでデータ量の増加にもつながる。
アップリンクコマンドはシンプルなものとし、アップリンクの成功率を向上させる
ためにも、少ないバイト数でコマンドをアップする工夫をすべきである。また、コマンドの暗号化はアップリンクの成功率を下げるだけなので、秘匿性の低い大学衛星においては得られる利益は少ない。
運用人員が減ってきても運用できるよう、地上局ソフトウェアが遠隔操作・自動運用に対応できるように設計することが望ましい。
パワーリセットをする際には、リセット前の姿勢制御パラメータやハウスキーピン
グデータの履歴を残すことが望ましい。姿勢制御パラメータは何回のパスにも亘ってアップリンクしなければいけないことがあり、リセット毎に初期値に戻ってしまうと、姿勢制御に多大な手間がかかる[3 のプロジェクト NO.34]。また、ハウスキーピングデ
ータの履歴は不具合原因究明に大きく役だつ。
5.7 試験しやすい、製作しやすい衛星設計
衛星設計においては、「試験しやすさ」や「作りやすさ」を考慮した設計をすべきである。衛星製作において、ファスナー（ネジ類）、ハーネス（ケーブル）、コネク
タは欠かせない。それらの絶対量や種類が少なければ少ないほど製作は容易である。
特にハーネスとそのコネクタはワークマンシップエラーが起きやすいところであり、使用を最小限にとどめる設計を心がけるべきである。ハーネスを使用せざるを得ない
場合は、学生の自作ではなく、プロに外注するのが望ましい。また部品の取り付け間違いを防ぐための工夫も必要である。PCB 基板の実装を表裏間違えて依頼するというよ
うなことは起こりうるが、表裏を間違えない工夫が必要である。「作業者が注意する」というようなことは解決策ではなく、間違い防止策が設計に反映されていなければな

24

らない。
システム試験、特に最初のシステム機能試験、を行なっていると、問題のあるコン
ポーネントをとりはずす必要に迫られることが多々ある。衛星全てを分解するのではなく、部分的な分解で済むような設計をこころがける。また、コンポーネントの取り外しの際、コネクタ部分での脱着を行うが、コネクタは繰り返しの脱着に耐えるものでないといけない。無理にとりはずすとコネクタを傷める場合もあるので、安全にとりはずすための工具を工夫するなどした方が良い。電気的インタフェース試験やソフトウェア開発は衛星システムを全て構体内に組み込まなくても可能であり、試験用のテストベッドを準備することを勧める。
衛星を組み立てた後でも衛星内の各種プロセッサ（マイコン）にアクセスできるよ
うに、アクセスポートを衛星の外側に設けておく。余程の自信がない限り、内部プロ
セッサに外部からアクセスできない状態にすべきではない。また同一設計の衛星を複数組み立てる際には、衛星ごとの識別が可能となるような外観上の工夫をすべきである。例えば図 3 では、各衛星の GPS アンテナにシールを貼ってある。
試験中・組み立て中の事故防止のため、衛星の組み立て、保管、機能試験等に使われる治具（図 4 と図 5）も製作することを勧める。衛星を直にテーブルの上に置くことは傷がついたりすることがあるので避けた方がよい。また、衛星をどのようにして持つかを考えた設計をすべきである。CubeSat の場合、移動時にはペリカンケースなどに入れて移動させるが、振動試験や熱真空試験などのセッティングでは、最後の瞬間は手持ちになる（絶対に片手でもたない）。CubeSat でない場合は、吊り上げ用の Ibolt を衛星上部の構造体に取り付けられるようにする。衛星を手でもつことは考えない方がよい。

図3

衛星保管用の治具

25

図4

図5

コンポーネント試験用テストベッド

システム機能試験時の様子（衛星は試験用治具にのっている）

5.8 設計根拠の理解
人間は自分のよくわからないことに、「たぶん大丈夫」という正常化バイアスをしがちで、意味もなくその判断を正当化しがちである。衛星開発において、「多分**」
や「**だろう」は禁物である。確固とした根拠に基づいた設計が必要である。特に、衛星の生死やミッションの成否を決めるクリティカルな設計項目では、自らが納得するまで設計根拠を理解する努力を怠るべきではない。わからない時にはいろんな人からの意見を聞くべきであり、設計や検証の方針を定める際に経験者のコメントを真摯に受け止める工夫が必要である。わからないことを「わからない」と自覚することが大事である。特に 2 号機以降の開発では、過去の設計を踏襲することが多いが、その設計根拠への理解を曖昧にしたまま、良かれと思って設計の変更をすると思わぬところで不具合が発生する可能性がある。例えば、シングルイベントラッチアップから抜け出すための過電流保護回路の閾値（本来は放射線試験によりラッチアップ電流を測定した上で決定すべき）など[3 のプロジェクト No.25]、その数値がどのような経緯で決められたかを理解しておく必要がある。
5.9 FM に移行する前に

26

EM 段階では衛星機能の完成と開発チームのスキルアップに注力する。そのためには、
機能的に FM と同等（太陽電池を除く全てのコンポが実装されている）の FM 予備機に相当するような EM を製作し、徹底的な試験を行う。実際の衛星システムをチームが触り試験を行うことにより、衛星を取り扱う作業の練度も確実にあがる（このことは未経験者が多数をしめる大学衛星では重要）。EM 段階でシステムとして最低限のミッシ
ョンが達成できることを End-to-End 試験で確認し、FM 移行後に根幹の部分の出戻りがないようにする。
EM 段階で確認されていない機能は、ミッション達成に絶対必要でない限り、FM に搭載しないという思い切りが必要である。FM 移行後でも新たな不具合は当然起きるが、不具合への対処は、金銭的・時間的・精神的に高くつく。FM 移行時に発覚した不具合
は、ミッション達成にクリティカルでないものは切り捨て、重要度の高いミッション
項目に資源を集中させるなどの覚悟も必要である。
このような判断をするためにも、ミッションが複数ある場合、どのミッションの優先度が高いか、「最低限達成しないといけないことは何か（=サクセスクライテリア）」をプロマネのみならずチーム全体で共有することが必要である。
また、FM での作業はクリーンルーム（クリーンブース）で実施することが多い。衛星プロジェクトに初めて参加する場合、クリーンルーム環境での作業経験がない場合がほとんどであるので、FM 移行前にチーム全員でクリーンルーム環境での作業のルールを確認すべきである。
5.10 安全要求適合性確認
詳細設計が終わり EM の試験が完了したところで、通常は安全審査 Phase0/1/2 が実施される。安全審査のための文書作成には非常に多くの時間を要する。安全審査担当
でなく、プロジェクトメンバー全員が高いモチベーションをもって臨むべきである。
安全審査 Phase0/1/2 においては、FM 品が安全要求に適合をしていることを検証する方法についても審議を行う。この検証方法については、安全審査を担当しているメンバーと実際に FM 製作と検証を行うメンバーとの間で意思疎通をはかり、検証が間違いなく行われるように注意しておかないといけない。コミュニケーション不足から検証が正しく行われず、打ち上げ前の安全審査 Phase3 において検証結果が不適合とされる危険がある。その場合は、無論検証作業のやり直し、最悪の場合は設計やり直しで、多大な時間的損失が発生する。

27

6. 製作
6.1 品質管理
超小型衛星に使用される部品は、宇宙用部品ではなく大量生産される地上民生部品がほとんどである。それらは大量生産品としてメーカー側で品質保証がされており、欠陥品が含まれる可能性は低く、個々の部品を衛星側で検査する必要はない。故障が生じるとしたら納入後の不適切な取り扱い（静電気、湿気、汚れ等々）による場合が殆どである。そのため、静電気ストラップをつけて作業する、作業前に周辺機器や作業テーブルの接地を確認する、手袋をつけて作業する等々を文化としてチーム内に浸透させるべきである。
個々の部品の品質は保証されていても、それらがコンポーネントとして製造された際に品質が保証されているとは限らない。大学衛星では基板の自作やインターネット
発注による実装サービスを使っている場合が多い。それらのコンポーネントは基本的に一品モノであり製造工程が確立していない。同じコンポーネントを複数製作しても、全てが良品であるという保証はない。そのため、コンポーネントが納入された際には、システムに組み込む前に基本的な動作試験をして、欠陥があるかどうかを調べるべきである。
6.2 作業外注と内製
大学衛星においては、衛星をすべて自分で作るのではなく、外注するところは外注するという割り切りが必要である。外注する予算がないから内製するという判断は、
スケジュール遅延やミッションの失敗につながる。大学衛星において、ハンドスキルが必要とされるところ（ハーネス、太陽電池パネル、半田付け等々）を学生にさせるかどうかは、慎重に判断すべきである。ハンドスキルに優れた学生も中にはいるので、それらの学生を見出して作業をさせることも可能であるが、それらの人材を見極める
自信がなければ、外注をするのが良い。教育衛星の目的は、ハンドスキルを身につけることではなく、システム工学とプロジェクトマネージメントを実践で学ぶことである。
外注の機器を買ってくる、または前のプロジェクトで実証できた機器を使用するな
どでコンポーネント自体に新規開発要素がない場合、学生はモチベーションが湧かな
いかもしれない。しかし、大事なのはそれらの機器をシステムとして組み立てた時にシステムとして動くためにはどのような試験が必要か、他の機器との噛み合わせをいかにおこなうかを、システム開発全体のスケジュールと歩調を合わせながら考え実行
していくことであり、それらの過程で得られるシステム工学とプロジェクトマネージ
メントの教育効果は機器を新規開発する以上に大きい。
また外部から購入したコンポーネントを動かしてみて動かないことが多々あるが、機器に問題がある場合もあるが、当該機器の正しい取り扱いがなされていないことに原因がある場合も多い。そのためには、機器が取り扱いやすい、問い合わせ対応が良好、マニュアルが親切といった観点を業者選定で考慮するとともに、動かない原因を自分達なりに真摯に考える努力も必要である。

6.3 安全要求適合性確認
FM の製造段階での記録は、安全審査 Phase3 での重要な検証文書の源泉となるものである。そのため、FM の製造段階では、できる限り多くの記録を残しておく。記録をとるとは単に写真を撮ることだけではないことに注意すべきである。何を検証するため

28

にどのようなデータや写真が必要か、を正確に理解し記録する必要がある。特に、構造部品の材料証明、組み立て手順書通りに作業がなされた証明等が重要である。衛星の組み立ては複数名を原則として、１名は手順書確認と記録に専念しなければならない。
7. 試験
7.1 電磁適合性試験
超小型衛星の場合、打ち上げ時には電源を OFF しているため、通常は他の衛星やロケットとの間での電磁干渉を考慮する必要はない*注（ただし、間違って電源が入った際の RF 放射による安全上の懸念はあるので、安全要求では RF 放射を許容値以下に抑えることを求められている）。電磁干渉については、衛星自身が出すノイズが衛星の動作に及ぼす影響が重要であり、特にアップリンク受信に対する影響を考えなければいけない。FM を使った End-to-End 長期運用試験で衛星内のノイズによりアップリンクが通じないことがわかっても手遅れである。そのため、EM の段階で十分な通信マージ
ンがアップリンク回線で成立することを試験において確認すべきである。
まず、通信機の EM が納入された時点で、その受信感度を理想的な状態で計測する。
通信機をシールドボックスにいれ、外部から RF ケーブルにてシグナルジェネレータ等で駆動した信号を入力し、受信機がアップリンク信号をデコードできる最低の信号強度を測定する。この信号強度は受信機自らが出すノイズフロアーにおいてデコードできる信号強度の最低値を意味する。実際に通信機が衛星内で組み込まれアンテナを取り付けられた状態では、ノイズフロアーが上がることはあっても下がることはない。
またアンテナで受信することにより、様々な追加損失（ライン損失、偏波損失、ポイ
ンティング損失、反射損失等々）が発生する。これらを考慮すると、受信機単体がノイズフリーでケーブルを直結して計測した理想的な状態でかなりのマージンがなければ、通信は成立しない。
キューブサットであれば、図 6 のように衛星全体をシールドボックスに入れた試験を実施することにより、他の機器によるノイズの影響を評価できるので、ぜひ実施すべきである。また、キューブサットよりも大きな衛星であっても、電波暗室であれば、アンテナ損失のいくつかの項目も加味した試験が実施可能である。これらの試験は、通信系の設計が要求を満たすかどうかを検証するために EM 段階で実施すべきである。

図6

シールドボックス内での受信感度試験

注：MOSFET をインヒビットスイッチに使用している場合、FET のゲートに接続するラインが ISS の放射電場によって励起され FET が作動する可能性がある。そのため、FETのゲートにはプルアップやプルダウン抵抗を入れる設計にする必要があり、なされていない場合は解析・検証などが必要になる。

29

7.2 End-to-End ミッション試験
EM 段階において、地上局との間での End-to-End 試験を実施して、最低限のミッションが達成できることを確認すべきである。この End-to-End 試験では、地上局からコマンドを衛星に送り、衛星の受信機でコマンドを受信して、それを C&DH 系に送り、C&DH
系からミッションペイロードにコマンドが送られ、ミッションを実施したあとにそのデータを送信機に送り、送信機から地上局にデータが転送され、地上局のコンピュー
タでミッションデータを可視化できることを確認する。例えば、地球撮影ミッション
であれば、シャッターコマンドを地上局から送り、地上局で画像を確認できるところまでを指す。このようにミッションの幹の部分を先に完成させ、それが実施できることを試験により確認したのちに枝葉の作り込みにかかる。この試験は電波を空中放射して行うことが望ましいが、電波暗室等を使用できないのであれば、有線ケーブルを地上局模擬通信機と衛星通信機の間につないで実施しても構わない。
7.3 電気的インタフェース（噛み合わせ）試験
コンポーネントが納入された後、衛星構造の中にコンポーネントを組み込む前に、衛星の他のコンポーネントとの噛み合わせ試験を実施しなければならない。この試験は EM、FM のそれぞれで必要である。EM で OK だったからと言って、FM で OK ということは保証されていない。超小型衛星用コンポーネントは通常少量多品種生産で手作り要素が大きく EM と FM が同一ロットで生産されない。そのため全てのコンポーネント
が EM と FM で同じということはありえないからである。コマンド•データ処理系や電源系等と組み合わせ、機器の ON/OFF ができるか、データを正常にやりとりできるか、動作に異常がないかどうかを確認する。この際、各コンポーネントの取り外しが容易になるように、またコンポーネント付属のコネクタを傷めないように、試験用のテスト
ベッドを用意しておくことが望ましい。
7.4 システム機能試験
各コンポーネントが納入され、噛み合わせ試験が済んだ後は、速やかに衛星を組み立てて、全系合わせてのシステム試験に移行する。環境試験の前に衛星が問題なく組み立てられたことを確認するために、システム全体での機能試験を行う。その際に以下の事項を確認する。
a)衛星が軌道上に放出された瞬間から定常状態に至るまでのモード。これには衛星からのビーコンデータの受信、アンテナや太陽電池パドルの展開、回転抑制（デタンブリング）と太陽指向への移行等々を含む
b)初期運用で実施する全てのオペレーション。これには、衛星へのアップリンクとハ
ウスキーピングデータの取得、最低限実施すべきミッション（ミニマムサクセスクラ
イテリアに相当）のコマンド送信とミッションデータ受信を含む
c)定常運用で実施する全てのオペレーション。これには、フルサクセスクライテリアに相当するミッションコマンドの送信とデータ受信や各種姿勢制御を含む
d)パワーリセットやセーフモード移行と復帰など、衛星の故障対策として組み込まれている機能の確認
これらの試験においては、衛星から送られてきたデータの中身をしっかりと吟味することが大事で、各種ハウスキーピングデータやミッションデータが矛盾のないものになっているかどうかを確認しなければならない。例えば、ハウスキーピングデータ
であれば、バッテリーの電圧・電流が衛星機器の作動状態や太陽電池からの入力電力30と矛盾なく推移し事前に作った電力バジェット表と一致しているか、カメラが想定通りの写真を撮っているか、姿勢系のセンサーが正しい値を返しておりリアクションホ
イールや磁気トルカといったアクチュエータがセンサー入力に沿った動作をしているか、所定の電力と周波数で衛星から電波がでているか、等々である。これらのシステ
ム機能試験で異常が見つかった場合は、環境試験に移行する前に問題を解決すべきである。この時点でのトライ&エラーには、非常に多くの時間を要するので、スケジュー
ル上は十分なマージンを持たせないといけない。衛星を初めて組み立てて１週間後に熱真空試験を行うというようなスケジュールはたてるべきではない。
7.5 End-to-End 長期運用試験
ミッションに失敗した大学衛星の多くが、スケジュールの遅れにより衛星納入前にFM の全系を統合した状態での長期間の End-to-End 試験を実施できなかったことを原因としてあげている。FM の End-to-End 長期運用試験には次のような側面がある。
a)フライトソフトウェアのバグ出し
FM までにすでに EM でシステムとしての機能試験は行われているはずであるが、FM以降後に付け加えられた細々としたソフトウェアアップデートを検証しなければならない。ハードウェアと直結した組み込みソフトウェアはプログラム用のシミュレータ
PC の上で動いたとしても、実際のシステムで動く保証はない。衛星が軌道上に放出された瞬間から運用終了に至るまで、衛星が迎えるあらゆる局面（正常時だけでなく、
非常時も）を想定してソフトウェアが正常に機能することを確認しなければならない。
この試験ではミッションコマンドの送信とミッションデータの受信も含まれ、ミッシ
ョンが実行できるかの確認も行う。
この試験はシステム機能試験とほとんど同じであるが、長期運用試験では、実際の軌道上の最初の１週間程度を実時間で模擬することが望ましい。その期間が最も不具合の発生する期間だからである。ソフトウェアにバグはつきものであり、時間が経つにつれて、バグの発見頻度は小さくなるが、長期運用試験はすればするだけ、衛星の信頼度は向上する。ただし、ソフトウェアの書き換えは、それ自体が新たなバグをもたらす危険性を秘めている。納入前のある時点を過ぎたら、たとえバグが見つかったとしても、重要度によっては書き直さないという判断も必要である。
b)運用リハーサル
End-to-End 長期運用試験は、地上局の操作ソフトウェアを使ってなされるべきである。衛星とのやりとりは基本的にはアップリンク・ダウンリンク信号によってのみ行う。それにより、衛星から送られてくるハウスキーピングデータから衛星の状態を知る術を見につけ、ミッションデータの処理方法を習得する。更に、アップリンクコマ
ンドに対する衛星の応答を知ることができる。地上局操作ソフトウェアを使うことにより、運用チームの練度を向上させることができる。衛星が目に見えるうちに運用訓
練を積むことで、見えない衛星と電波だけでやりとりする不安を解消させることができる。
c)地上局-衛星間の通信の確認
End-to-End 長期運用試験において、衛星と地上局の間は、できるだけ電波信号でやりとりすべきである。もちろん免許の問題をクリアするか、そうでなければ電波暗室で実施するしかないが、実際に電波でやりとりすることにより、通信回線計算を確認することができる。超小型衛星の通信回線計算において、正確に知ることが難しいのは、衛星側のアンテナ-通信機間の損失と通信機周辺のノイズフロアーである。アンテナ-通信機間の損失はアンテナおよび周辺回路の製作と取り付けのハンドスキルに左右31される。また、キューブサットの場合は各機器が隣接しており、通信機周辺のノイズ
環境は複雑を極めている。特に、図 7 に示すようにアップリンク信号は空間損失によって衛星到達時には極めて弱くなっており、上記の二つの要素（衛星納入後は手が出せない）はアップリンクの成功率を大きく左右する[3 の事例 28]。通信回線が成り立つかどうかを試すには、FM の実機に対して強度のわかったアップリンク信号を空中電波によって送り、アップリンクの成功/不成功を測定するのが実際の環境に即している。
さらに、実際の飛行状態ではドップラーシフトの影響が加わり、アップリンクの成功率は更に低下することを考慮すべきである。

図7

通信回線リンクバジェット（アップリンク）

7.6 展開試験
展開系を伴う多くの超小型衛星がミッション失敗に終わっている。多くのキューブ
サットがテグスでアンテナを保持する展開型の UHF/VHF アンテナを搭載しているが、大学発キューブサットの 1/4 程度が DoA(Dead on Arrival)に終わっている(文献[2])ことを考えると、このアンテナの展開に失敗している可能性も少なからずある。アンテ
ナだけでなく、太陽電池パドルの展開に失敗している衛星も数あり、膜展開や親機・子機分離を伴う衛星も成功率は高くない。
これらを考えるに、地上での展開試験が不足しているのではないかと思われる。微小重力・真空という地上と異なる環境で可動部品を動作させるのは確かに難しいが、コンピュータシミュレーションが難しい分野であるがゆえに、EM や FM という現物を用いた検証が欠かせない。EM においては、あらゆる悪条件を想定した上での試験を繰り返すべきであるし、できるだけ軌道上環境に近づけた条件での試験を行うべきである。
テグスをヒートカッターで切るタイプの展開アンテナは、衛星分離・放出直後でバッ
テリー容量が低下している状態且つヒートカッターが低温にさらされた状態でも展開可能であることを確かめるべきである。(図 8 に低温環境下での展開試験の例を示す。)展開機構は、複雑になればなるほど多くの試験が必要であるが、試験のしやすさを考慮した設計、試験回数の上限に余裕をもたせた設計とすべきである。試験環境も、
微小重力・真空環境に近づける努力を怠るべきではない。

32

図8

恒温槽内での低温環境下アンテナ展開試験

7.7 フィットチェック
この試験の目的は、衛星とロケットの間の機械的インタフェースが合致するかを調べることである。CubeSat の場合、POD の中に CubeSat が滑らかに入り、滑らかに出てくるか、衛星のエンベロープの逸脱がないか（衛星表面に取り付けられた物が POD 内壁に接触しないか）を調べる。最近は、分離機構を大学衛星側が開発・提供することは稀である（余程の理由がない限り分離機構を大学側で開発することは避けた方が良い。分離機構の安全性検証は、衛星の安全性検証以上に大変な場合がある）ので、打ち上げ事業者側から提供される分離機構（PAF-239M 等）や POD と衛星が機械的に合致するかどうかを調べるだけでよい。
CubeSat の場合、各構造部品が図面通り作られたからと言って、組み立てられた状態
で CAD 図通りに組み立てられるとは限らない。歪みなどは必ず発生する。1U 衛星であっても、衛星引き渡し時に POD に入らないということは発生している。衛星サイズが大きくなれば歪みも大きくなるので、より注意が必要である。フィットチェックの最も簡単な方法は、打ち上げ事業者の提供する「公式 POD」を使って、衛星を入れてみることである。これは EM と FM のそれぞれの段階で実施することが望まれる。
しかし「公式 POD」などのフィットチェック用治具は期間を限定しての貸与であり、借用時期をあらかじめ綿密に打ち上げ事業者と調整しておかなければいけない。また
それらの治具は「宇宙用」として製作されており、非常に高価であるので、取り扱いには最新の注意を要する。治具の一部であっても万が一破損させた場合の弁償額は非常に高価（数百万円単位）になることがある。実際にそのような事例がある。
7.8 熱試験
熱試験は、超小型衛星であろうと大型衛星であろうとやることは同じである。そのため試験方法に差はない。

33

ただし、１U の CubeSat 程度であれば真空と大気環境での温度差はそれほど大きくないので、恒温槽での高温試験と低温試験で熱真空試験の代替としても構わない（文献[8]の Annex-F を参照）。その場合でも、衛星全てを真空容器の中にいれて常温での機能試験を一度は実施すべきである。
超小型衛星の場合、能動的な温度制御はバッテリーヒータ以外に殆ど行わないので、熱平衡試験は熱解析のためのデータ取得や解析結果の検証を目的として行われる。しかしながら、今や多くの超小型衛星が軌道上で運用されており、軌道上温度のデータが蓄積されている。特に CubeSat は表面の多くが太陽電池で覆われており、表面の熱放射特性に大差はない。そのため、同じ軌道を飛んだ CubeSat の温度データがあれば、運用時の最高温度と最低温度を使って、熱試験の高温・低温の温度条件を導出した方が熱解析の手間が省ける。ISS 放出の CubeSat はそれこそ多くのデータが蓄積されており、それらの利用が推奨される（文献[9]）。ISS 放出の場合に注意すべきは、ベータ角が高く全日照の状態があるので、高温条件の導出には全日照時のデータを使用することである。
7.9 振動試験
振動試験は、超小型衛星であろうと大型衛星であろうとやることは同じである。そのため試験方法に差はない。振動試験報告書は、安全審査における重要な検証文書となるので、明確に書くことが求められる。
7.10 試験コンフィギュレーション（Test-as-you-Fly）
試験は、実際の飛行状態に近い条件で実施すべきである。実際の運用コマンドを送り、それに対する衛星からのデータを地上局ソフトで解析して、衛星の状態やミッシ
ョンの成否を判断すべきである。飛行時には衛星には外部ケーブルがついていないので、システム試験においては外部ケーブルは極力外すことが望ましい。外部ケーブルを介して思わぬノイズが混入することがある[3 のプロジェクト No.25]。ミッション機
器については、真空環境において衛星システムに組み込まれた状態で機能する（単にスイッチが入って模擬データを送るのではなく、実際に測定したりデータを中継したりする）ことを確認すべきである。
7.11 外部試験機関の利用試験設備を全て自前で揃えている機関は限られており、外部機関での試験を余儀なくされるプロジェクトが多い。試験に関しての経験が乏しいプロジェクトの場合、衛星設計や試験についての助言をできるだけの経験をもった試験機関を選ぶのが望ましい。外部での試験は、決められた時間内に所定の試験を終わらせることが求められる。
そのためには、事前に試験機関と試験仕様書なり試験計画書を使った打ち合わせが欠かせない。試験目的と試験条件を明確にし、どのような機材を持ち込む必要があるのか、試験機関から得られるサポートを、事前の遠隔会議などを通じて明確にしておくべきである。
7.12 試験結果の評価
試験結果の整合性を正しく評価する努力を怠るべきではない。よくない試験結果、気になる試験結果をそのままにしておくと、思わぬバグが潜んでいる可能性がある。
事前に試験の Pass/Fail criteria を明確にしておくのは当然であるが、時に許容範囲ギリギリのどちらとも言い難い結果がでることがある。そのような時は、なぜノミナ

34

ルの値からずれたのか、自分達で説明を試みるべきである。また、不可解な事象がランダムに起きる場合（スイッチが入らない、異常停止する、機器間の通信がうまくいかない等々、熱真空試験等で多い）、気づき事項は必ず記録に残し、解明を試みるべきである。正常化バイアスによって「多分気のせい」「軌道上では起きないだろう」
といった楽観視は禁物である。[3 のプロジェクト No.18]電波試験等においては、専門的な器材を用いることが多く、器材の操作を間違えて電波信号強度を読み誤ることなどもある[3 のプロジェクト No.28]。一人の人間に試験セットアップを丸投げすると、間違いに気づかずにいる危険がある。試験計画書並びに試験報告書を複数で吟味する体制が望まれる。
衛星の試験が全て終了して、納入待ちとなる前にチーム内でレビュー会を開催し、それまでに発覚した不具合への対応がしっかりなされたかどうかを不具合管理表を見ながら確認すべきである。
7.13 不具合対応試験を行った結果、不具合が発生することは必ずある。逆に言うと、試験は軌道上で不具合が発生する前に地上で見つけて修理するためにある。「2.7 不具合管理」でも述べたように試験中に見つかった不具合は情報を集約し、優先順位をつけて対処する。優先順位をつける際には、リスク管理をしっかりと行い、軌道上でその不具合が発現したとして、ミッション遂行に与える影響を評価しないといけない。故障解析においては、FTA を駆使すべきであり、それが打ち上げ後に不具合が発生した時に実施す
る FTA の予行演習ともなる。FTA では論理的な思考が求められ、頭を冷やして考えることが大事である。
また不具合に対応して衛星を分解したり、改修後に再試験を行ったりする時は、衛星に与えるストレスの影響を考えるべきである。コネクタの抜き挿し回数やファスナーの使用回数には制限があり、衛星の分解•組み立て毎にそれらの部品にストレスがかかる。振動試験などは累積疲労を衛星各部に与えるので、再試験として AT 試験を再度全て実施すべきかどうかは慎重に判断すべきである。

7.14 衛星の保管
全ての試験が完了した状態から納入まで、予期せずして時間がかかることがある。
打ち上げロケットの遅延、安全審査の長期化、電波免許の遅延等々理由は様々であるが、そのようなことは起きうる。衛星を長期保管する際、分離スイッチに長期間のス
トレスがかかって部品の変形につながる危険があるので注意が必要である。また、
時々衛星バッテリーを補充電するが、充電作業は複数で手順書に従って行う。慣れていると思っていても、ヒューマンエラーは防げない。バッテリー充電の際に間違ったピンを触らないような工夫を設計に組み込むべきである。保管中の衛星の起動やアンテナの誤展開等を防ぐフライトピンを設計に組み込むことなどを考慮することも勧められる。
7.15 安全要求適合性の確認
FM の試験が完了したのち、その結果を元に安全審査 Phase3 が実施される。安全要求に準拠する形で衛星が作られたかを、様々なエビデンス（検証結果）を元に吟味する場である。検証文書は安全審査 Phase2 で打ち上げ事業者と合意した検証項目に対する結果を全て記載する必要がある。検証文書は、試験完了後に一気に送るのではなく、

35

FM の製造・試験段階から打ち上げ事業者とその中身について調整を始めておくことが
望ましい。

36

8. 運用8.1 地上系準備・メンテナンス
地上系の整備は衛星納入前に完了させ、FM との間で通信が行えるかどうかを確認しておかなければいけない。地上系をおくべき場所としては、以下のようなことを考慮するのがよい。
a)周辺に高い建物がなく、低仰角まで衛星を見ることができる
b)直近にノイズ発生源（電波発信源）となるようのものがないc)アンテナの直近に無線機等を置くスペースがある。
d)無線機のある部屋は、快適に作業ができる環境にあり、普段の居室からの距離が近く、夜間でも立ち入りが可能である。
e)アンテナの置かれている場所には点検・メンテナンスのために容易にアクセスできるa),b),c)は通信回線の向上のためである。高周波の電気信号は同軸ケーブル中で簡
単に減衰する（減衰量は周波数とケーブルの仕様がわかれば簡単に計算できる）ので、c)は重要である。アンテナから無線機までの距離が長いようであれば、アンテナ直下
で低い周波数に変換することを考えた方がよい。
アンテナの設置場所を探す際にはどうしても a),b),c)に目がいきがちであるが、
d),e)も長期的な運用体制を考える際には必要であり、両者のバランスをとることが必要である。例えば、電波環境としては理想的な場所にアンテナが置かれていても、点検・メンテナンスのためにアンテナにアクセスするのに許可の取得・業者の手配（学生では立ち入れない時）等々で数日かかるようでは、緊急時にタイムリーな運用ができない。また、夜間立ち入りが許されていない建屋に無線局があると、夜間の運用ができず、可視時間の半分を最初から失うことになる。ネットワーク運用も可能であるが、軌道上放出直後のクリティカルな状況では全ての可視時間を使って運用すべきであり、ネットワーク運用に余程の経験がなければ、無線機の前に座って運用した方がよい。夜間の運用等を考えれば、普段の居室に近いことも必要で、夜間に可視時間が複数ある場合、可視と可視の間にどこで過ごすかも考えるべきである。真夏や真冬の運用を考えると、屋上の間に合わせのスペースに無線機を置かれていると作業が苦痛なものとなる。
アンテナは風雨に晒されるので、定期的なメンテナンスが欠かせない。アップリン
クが通りにくい、モールス信号の音が弱いと感じたら、アンテナの向きを調べるべきである。図 9 に八木アンテナのアンテナパターンの例を示すが、10 度中心からずれるだけでゲインは 10dB 下がり、通信マージンを食い潰す可能性がある。アンテナの向きを調整する際、コンパスが指す北は「地理上の北（北極）」ではないので注意が必要。
また、アンテナから無線機までの間は複数のコネクタを介してケーブルがやってきている。コネクタの接触不良、腐食等々も、地上局の不調の原因としてよく見られる。
地上系が正常に動いているかどうかは、実際に衛星からの信号を取得して、その電波強度を調べることによって確認することができる。自らの衛星の場合、衛星側に問題があるのか、地上系に問題があるのかわからない。そのため、基準となる衛星（長年に亘りビーコン信号を出し続けている衛星）を決めて、その衛星をトラッキングし、電波強度を計測することを勧める。

37

図9

地上局用八木アンテナのアンテナパターンの例

8.2 運用計画
超小型衛星は、宇宙空間での動作を保証されていない地上民生品で作られており、打ち上げ前の試験にも限界がある。そのため軌道上で予期せぬ不具合が起きることは避けられず、運用を始めて間もない段階で衛星を全損することも多々ある。そのため、実施すべきはa)バッテリーや太陽電池などの衛星の基本的生存に関わる機能を確認する。
b)衛星との上下通信回線を確立させ、「総合試験」を実施し無線局の本免許を取得する。
c)ミニマムサクセスクライテリアを実現するためのミッションの実施をできるだけ早期に行なう。軌道上放出後１週間以内が望ましい。初号機の場合、衛星から送られてくる CW モールス信号の解読、基本的ハウスキーピングデータの解析に目を奪われがちであるが、早急にミッションの実施に移行すべきである。CW モールス
信号に一喜一憂しているうちに衛星との通信が途絶した衛星は少なからずある。電波の本免許取得を急ぐのは、放出直後の運用はあくまでも予備免許での運用であり、予備免許だけでは衛星ミッションの成果の公開に制約があるからである。
8.3 不具合対応
8.2 でも述べた通り、超小型衛星はいつ通信が途絶するかわからない。そのような時でもあきらめないことが大事である。2 年間通信が途絶したのに復活した衛星もある。
そのためにはチーム内のモチベーションの維持が大事であるが、その場合最も大事な38

のは責任教員の姿勢である。たとえ衛星を失っても、その原因を徹底的に追求し、その教訓を次号機以降に反映することの大事さをチーム全員が共有することが、2 号機以降の成功に役立つ。実際に、初号機は失敗したものの 2 号機で成功した衛星は初号機の失敗について徹底的な原因究明を行なっており、その結果を 2 号機の設計に活かしている。成功はまぐれではやってこない。また、通信は途絶しないものの、メインミッションができない事態に陥ったりした時も、「死なない衛星」として軌道上の運用
データを取り続けることが、次の衛星の設計に運用上の教訓を反映する上でも大事である。
不具合（通信途絶も含む）が発生した場合、通信の流れにそった FTA を実施することを勧める。その場合、図 10 に示すように地上局->衛星->地上局の間の情報の流れに沿って、各ブロックの中身または各ブロックのインタフェースで不具合が起きていな
いかどうかを調べることを勧める。地上側に問題があるかどうかは、地上の予備機と地上局を使えば簡単にチェックできる。衛星側のどこに問題があるかどうかは、不具合事象の分析（観測された事象のみを列挙する、不具合の発生頻度、発生時期・場所の特徴等々）、衛星からのテレメトリーデータの解析（コマンドや衛星の動作の履歴を調べる、健全なデータと不健全なデータを見分ける、データのトレンドを見る）、予備機を使っての再現実験等々で、不具合原因の候補を一つずつ潰していくことにより調べる。FTA において大きな役割を果たすのが、フライトソフトウェアの最終版のソースコード、衛星設計文書、予備機などであるが、何よりも実際に開発に携わった人員がいると大きな助けになる。軌道上での不具合は起きたら回復不能ではなく、運用を工夫することで回復できることも多々ある。そのためにも運用チームが設計を理解していることが必要である。運用時に開発メンバーが残れるようにプロジェクトのス
ケジュール作成をすることが強く望まれる。また、予備機は運用時の不具合対策に極めて大きな役割を果たすだけでなく、FM 製作段階での作業ミスによって緊急に部品の代替品が必要となった時にも使うことができるため、予備機の確保を強く勧める。尚、予備機には EM を流用してもよい。

図 10 地上局->衛星->地上局の情報の流れ

39

9. 運用後
9.1 Lessons Learned
衛星プロジェクトで得られた教訓を次のプロジェクトで活かすため、あるいは実社会で活かすために、Lessons Learned は欠かせない。Lessons Learned をまとめるのに良い機会は、２つある。衛星を納入し終えた時と運用を終えた時である。ただし、運用が 2、3 年の長期に亘るようなプロジェクトの場合、中心メンバーが卒業する前にLessons Learned のまとめを行うべきである。また、責任教員はプロジェクトの実施期
間中随時メモ書きでよいので、気づき事項を備忘録に書いていくことを勧める。
Lessons Learned のまとめに決まったやり方はないが、プロジェクトに関わったメンバ
ーが率直な意見交換を行える雰囲気を醸成することが何よりも大事である。尚、Lessons Learned は活かされてこそのものなので、責任教員は次のプロジェクトの際には折にふれて過去のプロジェクトの Lessons Learned を引き合いに出すことを勧める。
9.2 記録化と成果報告・公開
衛星設計や試験結果についての文書化だけでなく、運用やマネージメントも含めた
プロジェクト全体の推移や記録をまとまった文章にしておくべきである。次のプロジ
ェクト実施に向けた重要な指針となり、次のプロジェクトに臨む学生達の参考になる。
プロジェクト全体を見渡していたプロジェクトマネージャーや責任教員が書くことが望まれるが、何らかの動機がなければ文章化も進まない。宇宙科学技術連合講演会やUNISEC の Space Takumi Conference などの各種報告会での発表は良い契機となりうる。
衛星プロジェクトを進める上で、外部機関や個人の方々の協力を得ているはずである。それらの方々にとって、衛星ミッションで得られた成果を報告することが何よりの恩返しである。そのため、ある程度成果がまとまった段階で、何らかの形でそれらの方々を対象とした成果報告会を実施することを勧める。その際の発表資料はプロジ
ェクトの記録として、後々様々な形で重宝される。また、衛星ミッションの成果は、限定された方々だけでシェアするのではなく、論文等により広く公表すべきである。
大学衛星の使命は人材育成と科学技術の進歩に貢献することにある。技術実証や科学観測を目的とした衛星は、最終的には対外発表という形で社会に成果を還元しなければならない。「教育」を目的した衛星であっても、教育手法としての超小型衛星という観点からみれば、衛星プロジェクトによってどのような教育的成果が得られたのかを公開して、他大学が参考にできるようにすべきである。これらの科学的または教育的成果の発表は、必ずしも査読付き学術雑誌への掲載という狭い意味での「論文発表」にとらわれる必要はない。ただし、責任教員や学生（特に博士学生）のその後のキャリアを考えると、査読付き学術雑誌への掲載が望ましいのは言うまでもない。
9.3 ノウハウ共有
超小型衛星のミッション成功のためには、それを支える衛星バスが確実に機能することが必須である。衛星バスの不具合によりミッションが達成できなかった例があまりにも多い。先進的ミッションを達成するためには、先進的バス技術が必要となるが、全てのバス機器を新規に開発し直す理由にはならない。軌道上実績を積み重ねた衛星バスについては、データ、ノウハウ、ソフトをコミュニティで共有して、「枯れた技術」を使うことが望まれる。ノウハウを共有するには、共有できる形にノウハウを加工しなければならない。共有には手間はかかる。最初から、いきなり立派な情報共有
プラットホームを作ろうとしても息が続かないので、できる範囲から始めることが望まれる。特に、軌道上データ（温度等）、軌道上での不具合の記録、搭載された部品40リストなどは需要が高いと思われ、そのようなデータをどんな形であれ、他プロジェ
クトと共有する姿勢をもつことが望まれる。

41

10. 大学衛星プログラムの持続可能化
10.1 プログラムとしての視点
個々の衛星プロジェクトではなく、一連のプログラムとして衛星バスやミッション
機器の改善をはかっていく姿勢が重要である。衛星プログラムとして着実に成果をあげていくためには、得られた教訓、知見、ノウハウをどのような形で蓄積していくかを十分に考えなければならない。大学衛星の場合、個々の大学や教員の状況により、一概に正解があるわけではないが、教訓を文書で残すだけでなく、肌で知った人間が残ることが望ましい。しかし、大学衛星では学生は卒業するので、それはほぼ不可能である。教員またはスタッフにその教訓を残さざるを得ない。スタッフの場合も、ポスドクなどの場合、雇用のための資金の継続的な確保、学内規則による任期、若手研究者としてのキャリア等の課題がある。教員に蓄積するには、教員がプログラムディ
レクターとして、各衛星プロジェクトに関与し続けることが必要である。
その他にも、学生の間に集団で残していく方法として、各世代の衛星プロジェクトをオーバーラップさせ、同時期に複数のプロジェクトが進行する中で先行プロジェク
トの運用結果に基づいて、先輩が後輩に伝授する方法もある。いわば「集団的知性（Collective Intelligence）」として経験を維持する手法である。ソフトウェアなど
属人的になりがちな分野ほど、この方法は有効と思われる。ただし、この方法は自転
車操業に陥る可能性があり、教員は、よほどの覚悟を決めて資金獲得等の努力をしな
いといけない。
持続可能な教訓の伝承体制を、責任教員の直下に学生だけがいる体制で構築するのは、教員に多大な負担を強いることになるため難しいと思われる。ポスドクや助教が中間層となって支えていくことが望まれるが、それら若手人材がアカデミックなキャリアを形成できるような工夫が必要である。
また、何回もの軌道上経験を経て技術が成熟したのちには、設計やノウハウを企業等に移管する、オープンソース化するなど、社会に還元する取り組みが望ましい。電子回路や構造など技術情報を図面の形で残せるものは、企業移管やオープンソース化
といった方法で「技術の属人化」を防ぐことができると思われるが、ソフトウェアなど個人的作業が主となるものについては難しい。殆どの学生は「他人が理解できる」
形でソフトウェアを書くトレーニングを受けておらず、情報分野を得意としない教員にはソフトウェアはブラックボックス化し、できるだけ多くのコメントをつけてソフ
トを書くように指導するくらいしかできない。現状は、オープンソース化してできるだけ他者の目で揉まれる機会を増やすなどの方法しかなく、ソフトウェアの伝承は大学衛星にとっての課題である。

10.2 学内基盤の強化
大学というものは、本来「個人商店の集まり」である。大学衛星プロジェクトは、
多くの場合は責任教員の研究室のプロジェクトとして実施されている。プログラムとして持続させ、成果を着実にあげていくためには、大学からの支援が必要である。ただし、大学からの支援を得るということは、大学へのリターンをもたらす必要がある。
そのため、自分の得意でない仕事も大学から依頼されることがある。それらを厭うのであれば、大学をスポンサーとすることは諦め、外部企業など別のスポンサーを探した方がよい。
大学からの支援を得ようとした場合、大学にとって衛星プロジェクトは受験生を集める広告塔の役割を果たすが、それ以上の価値が見出されなければ、大学からの支援

42

は限定的なものである。大学の教育あるいは研究またはその両方にとっての効果を示さなければいけない。教育面は、比較的容易である。昨今の工学部教育では、JABEE の影響もありデザイン能力が求められたり、Project Based Learning(PBL)をカリキュラ
ムに取り入れたりすることが求められている。とりわけ、学部教育では、専門分野に特化した教育だけでなく、幅広い視野をもたせるための教育が求められている。特に宇宙工学関連の学科では、「システム工学」が最重要科目の一つであり、座学だけでなく実践を通じて学ばせることが求められている。そのような時に、衛星プロジェク
トは恰好の題材であり、衛星プロジェクトに参加することで何らかの単位を得られる
ようにすることは難しくない。カリキュラムの一環となれば、大学側からの継続的支援を得ることができる。ただ、この場合は金銭的にはそれほど大きなものは期待できないので、注意が必要である。衛星プロジェクトが教員個人のプロジェクトから脱却するきっかけとして捉えるのが良い。
衛星プログラムの学内における位置付けをより大きく発展させようと思った場合、研究室間の連携が避けられない。「**先生のプロジェクト」から「**先生達のプログラム」への移行である。研究室間の連携では、チームメンバーの多様化、教員が増えることによるチーム内の専門的知識の拡大、衛星ミッションの多様化（理学系教員と工学系教員の連携の場合に顕著に現れる）、外部資金獲得の機会増大、等々といったプラス面がある。マイナス面としては、研究室の壁を学生が意識してしまうと学生間のコミュニケーションに齟齬が生じる危険がある。そのため、教員同士の日頃からの連携が欠かせない。研究室間の連携は、宇宙理学の教員との連携（科学観測ペイロードの搭載等）だけでなく、衛星から送られてきたデータの利活用でも考えることを勧める。特に、IoT や AI といった分野で、自前の衛星データを使ったパイロットプロジ
ェクトは、衛星作りには興味がなくてもデータ解析には興味のある教員には魅力的に映る可能性があるので、積極的な連携が期待できる。
10.3 資金確保
学内基盤が強化されたとしても、コンスタントに衛星を製作し打ち上げ続けるのに十分な資金援助が大学から出ることは稀である。そのための資金を確保する必要があ
るが、それは個々の教員が知恵を絞ってやっていくしかない。プロジェクト発足当時には予期していなかった要因（購入物品の修理や追加購入等）により、経費が嵩むこともあるので、資金計画には余裕を持たせておくことを勧める。科研費やその他の国の競争的資金にだけ頼っていると継続性が担保されないので、資金源の多様化をはかることが大事である。また、資金を確保すると同時に、衛星バスについては安く調達できるような設計を心がけるべきである。
10.4 外部連携プログラムとして持続的に衛星を作り続けるには、外部との連携が欠かせない。特にキーコンポーネントを供給してくれる企業との関係を維持することは重要である。
また、アマチュア無線コミュニティや JAXA と良好な関係を保つ必要性は言うまでもない。
プログラムを発展させていこうとした時に学内の他研究室の連携だけでなく、外部の大学・研究機関との連携も大きな効果をもたらす。特に海外との連携は、学生に国際経験を積ませる上で非常に有益である。衛星のミッションを考える際にも、外国で衛星利用を必要とするニーズが発掘できるなど、得られるところは多い。海外連携の場合、空間的距離や時差が障害となるが、衛星バスとミッションペイロードのインタ

43

フェースを明確にすれば、日本で衛星バス・海外でミッションペイロードの同時平行開発を行い、最終的に日本でバスに組み込んで衛星を納入といったことが可能であり、その例もすでに存在する。ただし、海外連携においては、安全保障輸出管理に関する手続きの要否を必ず確認し、公知の技術（オープンソースで公開されている情報等）
を用いない場合は特に念入りに確認することが望まれる。今では各大学に安全保障輸
出管理を扱う部署があるはずなので、当該部署と事前に相談することを強く勧める。

44

参考文献
[1] “Definition and Requirements of Small Satellites Seeking Low-Cost and FastDelivery”, Edited by Mengu Cho and Filippo Graziani, International Academy of
Astronautics, 2017, Code ISBN/EAN IAA: 978-2-917761-59-5[2]Michael Swartwout, Clay Jayne, University-Class Spacecraft by the Numbers: Success,Failure, Debris. (But Mostly Success.), 30th Annual AIAA/USU Conference on Small Satellites,
2016[3] NPO 法人大学宇宙工学コンソーシアム(UNISEC),超小型衛星ミッションサクセスのための Lessons Learned 事例分析, JAXA-CR-21-002, 宇宙航空研究開発機構契約報告, 宇宙航空研究開発機構(JAXA),2021[4]大野 耐一「トヨタ生産方式-脱規模の経営をめざして」ダイヤモンド社 1978 年[5] 「 小 型 衛 星 通 信 網 の 国 際 周 波 数 調 整 手 続 き に 関 す る マ ニ ュ ア ル 」
https://www.tele.soumu.go.jp/resource/j/freq/process/freqint/001.pdf[6] JBDB-08012D [成功基準(サクセスクライテリア)作成ガイドライン]、JAXA チーフエ
ンジニア・オフィス、2018 年 1 月[7] JX-ESPC-101132-DJEM 「ペイロードアコモデーションハンドブック, Vol.8., 超小型衛星放出インタフェース管理仕様書」 D 版、p.21, 2020 年 5 月[8]ISO-19683 “Space Systems – Design qualification and acceptance tests for small spacecraft
and units”, 2017.07[9] Adolfo Jara, Pooja Lepcha, “On-orbit Electrical Power System Dataset of 1U CubeSat
constellation for Machine Learning Models”, Mendeley Data, May 2022,
DOI:10.17632/8kp25ycf63

45