平成28年5月24日（火曜日）10時～12時
文部科学省 研究開発局会議室1
主査 佐藤 勝彦 主査代理 木村 真一 専門委員 白坂 成功 専門委員 野口 和彦 臨時委員 横山 広美
研究開発局宇宙開発利用課長 堀内 義規 研究開発局宇宙開発利用課企画官 奥野 真 【説明者】 国立研究開発法人宇宙航空研究開発機構（JAXA） 理事 常田 佐久 宇宙科学研究所宇宙科学プログラムディレクタ 久保田 孝
【事務局（奥野企画官）】 定刻になりましたので，ただいまから宇宙開発利用部会のX線天文衛星「ひとみ」の異常事象に関する小委員会を開催いたします。
委員の皆様には，御多忙のところ御参集いただきまして，まことにありがとうございました。御礼申し上げます。
本日は，平成28年4月19日に開催されました第26回宇宙開発利用部会において，JAXAよりX線天文衛星「ひとみ」の状況について報告を聴取した結果，専門技術的観点等から，第三者によりJAXAが実施した異常事象の要因分析の結果等について，技術的妥当性を検証する必要があると認められたため，本宇宙開発利用部会の下にX線「ひとみ」の異常事象に関する小委員会，本小委員会が設置された次第でございます。
本日は，本小委員会が設置されてから最初の会合となりますので，議事進行につきましては，主査にお渡しするまで，事務局の方で進めさせていただきます。
議事に先立ちまして，まずは本日御出席いただいております委員の皆様のお名前を紹介させていただきます。お手元の資料の参考1の中に，別紙2という形で添付されてございます。
本小委員会の主査は，日本学術振興会学術システム研究センター所長の佐藤勝彦先生にお願いしております。
【佐藤主査】 佐藤でございます。よろしくお願いいたします。
【事務局（奥野企画官）】 主査代理は，東京理科大学理工学部電気電子情報工学科教授の木村真一先生にお願いしております。
【木村主査代理】 木村でございます。よろしくお願いいたします。
【事務局（奥野企画官）】 委員といたしまして，慶應義塾大学システムデザインマネジメント研究科准教授の白坂成功先生にお願いしております。
【白坂専門委員】 白坂です。よろしくお願いいたします。
【事務局（奥野企画官）】 委員といたしまして，横浜国立大学大学院環境情報研究院教授，野口和彦先生に委員をお願いしております。
【野口専門委員】 野口です。よろしくお願いします。
【事務局（奥野企画官）】 続きまして，東京大学大学院理学系研究科准教授，横山広美先生に委員をお願いしております。
【横山臨時委員】 横山です。よろしくお願いいたします。
【事務局（奥野企画官）】 ありがとうございました。
続きまして，事務連絡，その他について，御説明申し上げます。
まず，本小委員会でございますが，宇宙開発利用部会の運営規則によりまして，定足数は過半数となっております。本日は，委員の皆様，5名の皆様全員に御出席いただいておりますので，定足数は満足しております。よって，本日の会議が成立したことを御報告申し上げます。
2点目は，本日の資料についてでございますが，お手元の資料の一番上にございます議事次第の4ポツのとおり，お手元に全ての資料を配付してございます。もし過不足がございましたら，適宜事務方にお申し付けください。
それでは，以降の議事進行を主査の佐藤先生にお渡しさせていただきたいと思います。佐藤先生，よろしくお願いいたします。
【佐藤主査】 佐藤でございます。利用部会におきまして，白石部会長より御指名いただきましたので，主査として，本日の以降の議事進行を進めさせていただきたいと思います。どうぞよろしくお願いいたします。
【佐藤主査】 それでは，早速，議題に入りたいと思います。
本日の議題は，X線天文衛星ASTRO－H「ひとみ」の異常事象の要因分析結果の妥当性の検証でございます。
X線天文衛星ASTRO－Hは，第27回の宇宙開発利用部会におきまして，JAXAより運用断念の報告がございました。今後は原因究明に専念するとの御報告が出されております。
本小委員会では，JAXAの全プロジェクトへの影響の有無を見極める必要もございますし，また，背景要因を含めた原因究明と再発防止対策の妥当性について，調査，検討を実施したいと考えております。
JAXAから，本日までに究明された原因と，その対策，説明の報告をまず頂き，委員の皆様に御議論をお願いしたいと思います。
それでは，JAXAの方から御説明をお願いしたいと思います。よろしくお願いいたします。
【JAXA（常田理事）】 ありがとうございます。宇宙科学研究所長の常田と申します。本日は，資料1－1，X線天文衛星ASTRO－H「ひとみ」異常事象調査報告書に基づきまして，御説明をさせていただきます。
最初に，ちょっと資料の構成について御説明したいのですが，2ページ目の目次を見ていただきたいと思います。項目の5，異常発生メカニズムの要因分析に至るまで，本日，詳細に御報告させていただきます。6の対策・改善事項，7，まとめについては，次回以降の提示とさせていただきたいと思います。
それでは，説明は宇宙開発プログラムディレクタの久保田よりさせていただきます。よろしくお願いします。
【JAXA（久保田）】より資料1-1，1-2に基づき説明を行った。
【佐藤主査】 どうもありがとうございました。
ただいまの説明で，前回聞いていたときに比べると，シミュレーションの結果とテレメータの信号が取れたところのデータが一致していることなどから，ほぼ解明されているという印象を受けました。
それでは，ただいまの御説明に対して，委員の皆様から御質問をお願いしたいと思います。
【木村主査代理】 最初に発言させていただきます。
最初に，このような詳細な解析や，非常にデリケートな情報を含めて提示いただいたこと，大変感謝いたしております。解析作業を非常に積極的にやられているという点について，まず敬意を表したいと思います。
その一方で，例えば，スタートラッカがアクイジションに戻るという，ある意味，姿勢系にとってはあり得るというか，比較的想定され得る現象が，こういった深刻な事故につながってしまったという点を深刻に受け止めておりまして，私もFDIRとか設計に関係する立場から，非常に深刻な問題だと思っております。以降の衛星に関連もしますので，幾つか質問させていただきたいと思います。
先ほどの説明で，私，気になる点は二つあります。一つは，各種設計のロジック。FDIRなり設計の考え方というのは，それぞれ何らかの理由の元に考えられていることは分かるのですけれども，それが総体として恐らく整合していない，あるいは整合性の確認が十分だったのかというところが非常に気になっています。
先ほど審査会等で議論になったというところまでは伺ったのですが，もし，その辺を，具体的などういう議論であったかということについて，議事録など具体的な記録について後日でも構いませんので提示いただくことは難しいでしょうか。ノウハウ等の関係で公開が難しいようであれば，委員の方にだけにでも展開いただけると，少し参考になるのかなと思います。
【JAXA（久保田）】 きょうは簡単にしか御説明しませんでしたけれども，FDIR，それからセーフホールドという考え方に関しましては，姿勢が非常に関わるわけですけれども，いろいろなところでの検討，あるいは冗長系に切り換えるというのがありまして，審査会の中で，それもプロジェクト外の人がいろいろ見て指摘していて，高止まり等，あるいはスタートラッカを外す等に関しても，そこで議論されていて，指摘もされていて，検討がありました。最終的には，一つは，その対策としては，運用で対処できるというような，判断があって，それがそのまま通ってしまったということになっています。
【木村主査代理】 そうですね。
まずは妥当性を議論するということですので，そこの経緯などが，もし，我々が知ることができるのであれば，少し知っておく必要があるのかなと思っております。これの部分の資料というか，説明として必要なのかなと。
【JAXA（久保田）】 はい。
【木村主査代理】 もう一点は，今の議論でも，お答えの中にも，まさにあったのですけれども，運用や設計の過程で，どういう経緯で意思決定がされていったのかというところが非常に重要かと考えます。例えば，設計から考えて，非常にクリティカルなパラメータを設定するときに，それが共有されていなかったとかいう話がありました。例えば，姿勢のスタートラッカで考えたときに，実際に軌道上でもアクイジションに戻るという現象が確認されていた。姿勢系のチューニングを実施しているにもかかわらず，姿勢変更の効率を優先して非可視領域で姿勢変更マヌーバーを実施する，など設計や運用の意思決定過程に問題があったように思われます。
運用時，例えば，ここでこういう実験や運用を行うということを決めていった経緯とか，その辺も少しオープンにしておく必要があるのかなと思います。
【JAXA（久保田）】 はい。
まず，スタートラッカのところの現象は，ある程度捉えられていて，一つ，地食ということに関しては，そこをスタンバイにして，全く使わないということで対応はしていたんですが，それ以外の現象についても調査中であったということ，そういう状況でありながら，それが運用に反映されていなかったということは御指摘のとおりで，その辺は運用に関して過小評価していたというところがありました。
それから，設計に関しましては，各審査会を行って，そこで指摘されたことの対応というのも行っていたわけですけれども，最終的に審査会等で議論になった結論が，運用で対処するというところが，それでは，具体的にどう対応するかというのが実際の運用に引き継がれていなかったというのが非常に大きな課題というふうに考えています。
【木村主査代理】 あと，もう一点だけ，ちょっと細かいというか，具体的な話で，むしろ白坂先生の方が御専門かもしれないですけど，先ほど姿勢パラメータについて，噴射時間が負にはならないはずだという話ですね。手入力で問題があったというのも，とりあえずありますけれども，それ以外にもガードを掛ける手立ては恐らくあったはずです。パラメータ変換するときに負になり得ないものが入っていたわけですから，運用システムでパラメータチェックするとか，姿勢制御系のソフトウエアでガードするとか，といった手立てはとられなかったのでしょうか。先ほどのパラメータの件は，正直，ちょっと刺激が強過ぎるというか驚きだったのですが。
加えてですが，1回しかないパラメータ変更だから，検証ツールの整備が追い付かなかったということなのですが，その一方，このパラメータは非常にクリティカルなパラメータだったわけですね。いざというときに，それに頼るしかないパラメータだったと思うのですけれども，そういう意味の判断というか，そういうのは，やはりなさらなかったのでしょうか。総括のところで述べられたように，することが十分ではなかったという御判断なわけですか。
【JAXA（久保田）】 まず，途中でツールのところで符号付きのものが出てくるのは，逆に符号を見て，正しいかどうかも判断していたと思うんですね。最終的なコマンドにするところで，いろんなやり方はあったとは思っています。ですから，そういうミスを防ぐようなメカニズムというのを，きちんとガードしていくところが抜けていたというふうに考えています。
もう一つの御指摘のところで，こういうパラメータをあらかじめ作っておいて，さらに打上げ前にも書き込んでおいて，それを使うようなロジックってあるわけで，打上げ前はそうしていたんですね。今回の制御パラメータというのは，打上げ後に使ったスラスタと同じロジックで作ったもので，打上げ前の試験で，打上げ前のスラスタのパターンというのは事前に作って，検証も行って作っていました。
もう一つ作っておりましたのが，スラスタの最後の状態。これは推力を使いますと，推力はどんどん弱くなっていきますので，一番弱い状態でも衛星として制御できますよという確認は事前に行っていて，その二つのケースにつきましては，パラメータも作ってあって，検証も行っていたんですね。ですから，今回は打上げ直後で，スラスタは使うわけですけれども，使った状態というのは分からないので，テレメトリデータから作って，より効率良くするために，追加で行った運用で，その辺の考え方ですね。それもクリティカルではあるんで，あらかじめ作っておいて，実際のデータを見て，若干変えるぐらいの，先ほど差分と申しましたが，そういうやり方か，あるいは多少変わっても，効率を犠牲にしてでも，とにかくあらかじめ検証されているものを使うという，そういう考え方もあったと思いますので，その辺の考え方が過小評価していたのかなというふうには今考えています。
【白坂専門委員】資料にも書いてありましたが，通常の衛星では，制御パラメータの変更はクリティカルなので，パラメータは変えない前提で，設計値を事前に入れておく，どうしても変えたい場合には，差分をコマンドで送るというのが通常のアプローチです。直接書き換えるのって，やっぱり怖いので，普通の衛星ではやっていないです。
私が開発に携わった「こうのとり」ではパラメータの直接変更をやっていますが，その場合には，噴射している方向と，実際に動いている方向の差分に対しFDIR掛けています。つまり，普通は変えないのを前提に設計しますので，今回も設計した人は，変えない方向で開発していたから，コマンドを用意してなかったのかもしれません。しかし，運用の中で，より良い制御を行うために，実測値を使って制御パラメータを書き換えるという形になったのかなと思います。
私の方からコメントですが，結局，すごく少ない情報から，発生のメカニズムの詳細まで分析してあり，ここまで追い込めたのはすばらしいと思っています。本当にこれだけの情報を出していただいて，有り難いと思っております。
ただ，このメカニズムを見ると，結構止められたポイントがあったと思います。幾つか止められるポイントがあったのに止まらなかったのは，ミスがいっぱいあったというよりも，さらにその奥に何か根本要因があるはずだと思っています。その根本要因が原因となり，いろいろな止めるべきところが止められなかったのではないかと思っています。「こうのとり」の開発時には，「飛ぶように試験して，試験したように飛ばすんだ」というのを繰り返し言われて，私どもはメーカーとして，開発時に，飛ぶように試験するというのはどういうことかということを考えました。設計時に飛ぶことを想定すると，すごくシンプルに考えないと設計ができないのです。よって，いかにシンプルな運用をしようとするか，そのために，いかにシンプルな設計にしていくかというのを考えると，やっぱりこれはすごく全体としての，システム全体としての設計のアプローチというか設計の方向性となります。特に，大きくて複雑になりそうだからこそ，いかにシンプルな設計にしてあげて，いかに検証を少なく，確実性を上げてあげてということだになってきます。ですので結局のところは，設計起因だと，正直，思っています。複雑な設計をしてしまうと，検証で網羅するというのは，やはり無理で，そうするとどうしても運用に任せる。運用に任せると，設計からの情報のトランスファーがすごく複雑で，何かを調べないと運用どうすればいいか分からない。そうすると，やっぱり抜け漏れが起きていく。ですので，シンプルな設計コンセプトで運用に引き継いであげて，運用の人たちも，すごくシンプルに理解しながら行う。全体のみならず，個別はもちろんあり，チェックはあるのですが，そういった，全体の設計観を作るときのアプローチが欠けているのかなと思います。
多分，複雑だったからこそかなという気もするのですが，本当は複雑だからこそ，シンプルな設計にしないといけない。今回の，ASTRO－Hは，大きい複雑な衛星ですので，そこが欠けてしまった。今みたいな，制御パラメータを変えるということは，とてもクリティカルで，本当はやりたくないとして，そうしたときに，それをよかれと思って変えようという話が出たときに，いやいや，それクリティカルだからやめた方がいいのじゃないという話が出てないとか。あるいはFDIRを見ても，コンビネーションで複雑なことを検証してないと駄目と言われても，それは多分，複雑過ぎると検証なんかで思い付いてないとか，パターンがあり過ぎて，そこまでは行ってないとか，いろんなところに起因しているのが，根本的な設計アプローチではないかと感じています。そういった意味では，一個一個は多分，優れた専門家の人たちも見て，チェックもされていて，そんなにおかしいことをやってないことも設計としては多いのですが，全体としての方向性が，やっぱり欠けてしまった。
例えば，スタートラッカ。設計方針としては，冗長系がコンセプトだと言っておきながらスタートラッカは違っていて，しかも，そのときに片系運用しているときにもかかわらず，それが関係するところで，余りマヌーバのチェックを，入れてないとか，そういうのは普通だと，これは片系にしているから，危ないからとか，もうちょっと，これ動きがおかしいから，もっと早く見ようよとか，何かそういう歯止めが，ぽっと出てこなかった理由は，やはり運用者も複雑過ぎて，全体観をつかめている人が少なかったので，そこに思いが到達し切れなかったのじゃないかなというのがあります。今回のメカニズムを見ると，何か本当にすごい狭い穴を通って起きてしまった事象なので，だからこそ，どこか根本があるんじゃないかという疑いを持った方がいいかなと思います。そうではなく，個別個別の対処を考えようとすると，とんでもないことをいっぱいしないと，これは防げなくて，複雑な設計をしていると，これら全部を本当に起きないように，全部の対処します，と言われると，普通の衛星でも，今の開発のアプローチだと，全然時間もお金も足りないぐらいのことをやらないといけなくなると思っております。
【佐藤主査】 いかがですか。
【JAXA（久保田）】 御指摘のように，今回，原因究明している中で起こった事象，何でこういう設計になっているのかと思うのですけれども，いろいろ深く見ていくと，それぞれのロジックは，確かにいろいろ考えてはいて，トレードオフもやっているのですが，やはりトータルシステムとしての考えというのがすごく抜けていて，こういうことが起こってしまったということと。確かにいろいろな試験はしてきたんですけれども，複雑過ぎて抜けてしまったのかというのは御指摘のとおりかなと思っています。これは冗長系を組んで，いろいろ，例えば，両方ともオンにしてチェックということはいろいろ組んでいて，何かあったら警戒をというのは，ある意味，冗長系で信頼性が高くなったふうに思ってしまっているんですけれど，逆に何かあったときに，そこが抜けていたというようなことで，確かに複雑なところもあったかなというふうに思います。
一方，もう一つ，スタートラッカは2個搭載しているけれども，ハード的な冗長にはしているけれども，していなかったところの理由としては，一つは，やはりサイエンス要求というのがありまして，スタートラッカの値で切り換えたりすると，値が違ってきて，それでまた収束するのに時間が掛かったりということと，もう一つ，スタートラッカの方向を同じにしているんですね。これが同じにしていますから，切り換えても助かったかどうか分からないところはありますが，違う方向を向いているとすると，違う星を見ていますので，違うデータが来た。ただ，違うデータが来ると，今度，姿勢決定値もまた違ってくるので，そこに移行する間に，また推定値に時間が掛かるという，その辺はミッション要求とシステム設計とのトレードオフの考え方というところにもあるのかなというふうには思っておりまして，その辺も含めて調査して，次回以降，どういうところの対策が必要かというようなことも議論させていただければなと思います。
【佐藤主査】 全体としては，高度な天文衛星なので，そのための観測時間の確保が当然ですけれども優先されており，おっしゃったように，システム全体を見て，安全性を保つことについて，設計の段階から甘かったというふうには聞こえますね。
【野口専門委員】 幾つか質問をさせていただいて，あとは意見を申し上げたいと思いますが。
最初に，制御パラメータが正確に入っていたとすると，今回の最終的な運用断念に至るような状況は防げたと思っていていいですか。
【JAXA（久保田）】 今回，最初にスラスタでのセーフホールドに入るということは，非常に大きな問題が起こって入るものですので，今回の原因であれば，スラスタで太陽を捕捉して，それからどのくらい掛かるか分かりませんけれども，復旧の可能性はあったというふうには考えております。
【野口専門委員】 ありがとうございます。
それでは幾つか質問に戻らせていただきますが，先ほどテレメトリデータを見ながら運用で修正することになっていたが，うまくいかなかったというお話があったのですが，例えば，43ページの，このZ軸のテレメトリデータを見ると，明らかに異常ですよね。
【JAXA（久保田）】 はい。
【野口専門委員】 この異常なものを見て，何も手を打たなかったというのは，その引継ぎがうまくいかなかったということ以上に，データを見ているということの意味をどのように捉えていたかというのは，どういうふうにお答えいただけますか。
【JAXA（久保田）】 すいません。ちょっと説明が悪かったのですけれども，緑色のところというのは海外局でレンジング運用しているところなので，実際にリアルでは見ていなくて。
【野口専門委員】 リアルでは見ていなかった。分かりました。
【JAXA（久保田）】 見てなくて，後で解析して分かったものです。クリティカル運用のときは，海外局も含めてリアル運用で見ていたんですけれども，初期機能確認に移ってからは，内之浦で1日運用した後は海外局で運用することになるのですけれども，それは姿勢決定は行っているのですけど，データだけ降ろして，次の可視で見るということで，これ，リアルでは見ていなかったですね。
【野口専門委員】 それは，逆にリアルで見ていたら対応できた可能性はあるということですか。
【JAXA（久保田）】 リアルで見ていたら，これは運用時間が約10分で，約90分ごとに運用があるんですけれども，最初，これを見たら，異常があることは，まずそこで分かったと思うのです。その次に対応を打てたかどうかというのは，それは状況によりますので何とも言えないのですけれど，次のデータも見てから何か対策を打ったと思いますけど，多分，最初に打つのがセーフホールドコマンドではないかと思いますので，結果論ですけど，どうなったかは，ちょっと何とも。
【野口専門委員】 分かりました。ただ，データを確認しているということが，単なるウォッチングなのか，何か手を打つための前提なのかという基本的な考え方が重要かなと思ってお聞きしました。
【JAXA（久保田）】 もう一つ，ちょっと付け加えさせていただくと，こういうふうに増えていったのは異常ですので，途中で姿勢系は，どこか異常があるということで，FDIRは実は掛かっています。セーフホールドはないのですけれども，機器の切り換えというのは途中で行っているんですけれども，原因がバイアスレートの推定値だったので，切り換えても状況は変わらなかったというふうに考えております。
【野口専門委員】 分かりました。
あと，次，52ページなのですけれども，最後にピクセル数の値に関して，打上げ時の初期設定値であったが，チューニングが必要であることが分かったために，軌道上調整を行う予定だったということなんですが，なぜ打ち上げた後の軌道上調整にすることにしたんですか。
【JAXA（久保田）】 地上でこういったスタートラッカのいろんな処理をするための設定値というのは，あらかじめ地上試験で決めていて打ち上げたんですけど，やはり打ち上げてから実際の星を見ると，温度環境とか，いろいろなことが違いますので。
【野口専門委員】 その補正はやるということですね。
【JAXA（久保田）】 補正はある程度は必要だと思ってましたけども，実際打ち上げてデータを見ると，捕捉モードに入るのが，かなり頻繁に起こっていた。スタートラッカというのは，放射線の影響とか，いろんな影響で外すこともあるのですけれども，チューニングの必要性というのは，打上げ後，分かった次第です。
【野口専門委員】 分かりました。
【JAXA（久保田）】 データを見て必要性は分かって，チューニングはいろいろしていたんですけれども，原因の特定に時間が掛かっていて，対応したチューニングも必ずしも効果が出なくて，それを調査中であったということで，スタートラッカは二つあるのですけれども，一つを使って調査をしていたということで，2個あるうちの一つはスタンバイで使っていました。
【野口専門委員】 分かりました。
あとは64ページなのですけど，いわゆる「スラスタ制御のパラメータの変更による検証の必要性が相手に伝わらなかった」という書き方になっているのですけど，逆に，こういう大事なものに関して，検証の必要性というのは伝わらないと検証をしないものですか。
【JAXA（久保田）】 これがきちんと手順に書かれていなかったのだというふうには思っていますけど，御指摘はよく分かります。
【野口専門委員】 幾つか言い方として多少明確でないところがあって。例えば，検証。検証した結果の確認を怠ったと書いてあるところもあって，要するに，検証したけど確認を怠ったのか，検証をしなかったのかというところが，よく分からないですけれど。
【JAXA（久保田）】 ちょっと文言が曖昧なところもありまして，正確に言いますと，検証を行ったかどうかの確認をしなかったということで，結果として検証がされていなかったということです。
【野口専門委員】 検証されてなかったということですよね。
【JAXA（久保田）】 はい。
【野口専門委員】 分かりました。ありがとうございます。
すいません。なかなか聞きづらいことをお伺いしたのは，別に誰がという，そういう原因を特定する気は全くなくて，実はFTA等も見せていただいたのですけど，今回の調査結果を見て，私の感じだと，何が原因かということに関しては，かなりよく分析していただいていると思っているのですが，なぜそれが起きたかということに関しては，いわゆる分析が足りないように思います。
これは，例えば，FTAを見ても思うのですけど，今回，FTAとして出されているものが，みんなOR事象がずっと並んでいるだけなのですよね。これは何が起きたかというのは，経験的なものも含めて，原因を揃えて，技術の知見としての整理としては十分だと思っているのですが，原因分析としては，基本的に，事故の場合は発生する原因があった。その発生する原因を止める手段が上手くいかなかったという，ここにAND事象があって，さらにその原因，発生してしまったものに対して，拡大を防ぐとか修正をするという機能が働かなかったという，何回かのAND事象が全て失敗することで，起きることによって事故まで拡大するわけです。しかし，今回のものは，やっぱり直接の原因が，これが起きましたというところで，なぜその起きることが途中で防げなかったかとか修正できなかったということに関して，幾つかの知見としては述べられていますけど，論理的な押さえ込みというのは，もう少しやっていただいた方がいいと思います。例えば，委員会等で，うまくできなかったとか，確認できなかったという事実は分かっていますけど，なぜできなかったのだろう。それは単なる技術の問題なのか，例えば，制度の問題なのか，お金とか期限の問題なのか，それによってもできなかった原因って違うわけですよね。そうすると，そこのところが明らかじゃないと，その次の修正のときに，対策が，やっぱり直接見えている原因のパッチ当てになってしまう。今回はたまたま，この原因で起きたかもしれませんが，同じような根本原因が潜んでいると，今度は次の別の格好で出てきますから，恐らく，なぜできなかったのだというところを，もう少し一踏ん張りしていただいて，それは技術の問題なのか，制度の問題なのか，費用の問題なのか，そういうところまで落とし込まないと，恐らく基本的な項目にはならないと思っています。
それから，最後にしますけれども，私はこういう，非常に高度な技術システムに関して，科学技術の開発におけるある種の試金石になっていると思っています。ある意味で，白坂先生とは僕は意見が違うのですけど，今までこういう高度技術に関しては，設計にかなり重きを置いてきた。したがって，設計者もいろんなことを考えて，装置を付けるということをやってくるのですけれども，設計者は当然のことながら，機能を達成するということと安全ということを両方考えているという中で，それでも，安全もよく考えてくれていると思っています。
ただ，やっぱり高度技術システムというのは事前に設計段階で考えた以上のことが起こるというのは前提としなくてはいけなくて，設計が完璧であればトラブルは起こらないというのが，ある種の安全神話につながっていたというのが，今までの高度システムですからね。そういう意味では，僕は設計と試験，それから運用というものを総合力で，どうやってその根本的なものを食い止めるかという一つのモデルが必要だと思っています。そういう意味では，今，先進的な科学技術に関しては，新しい機能を追求するということに関しては，開発であるとか，新しい試験であるとか，研究であるとかということは，非常に意義は認められていますけれども，こういう最終的に物事を安全に落とし込むとか，信頼度高く運用するとか，そういうことに関しては，何となく，人間が真面目にやっていればできるかのようなイメージがあるのですが，複雑系の場合は，人間が真面目にやっていても，そこにはある種の技術とか新しい仕組みがないと無理なわけで，そうすると設計というのは，対象となる衛星，ロケットの設計だけではなくて，こういう運用のための仕組み，試験のための仕組み，システムというものの研究開発が非常に重要なのだというのが私の先進技術に対する意見です。そのための予算，期間，それからスタッフということも踏まえて，それが十分だったかどうかという検証が必要なんじゃないでしょうか。
以上，これは意見です。
【佐藤主査】 ありがとうございました。
いかがでしょうか。
【JAXA（久保田）】 きょう，説明させていただきましたのは，異常発生メカニズムと直接原因と，幾つか背後要因も述べさせていただいていますけれども，御指摘のように，根本要因につきましては，また次回以降，議論させていただければと思います。
【佐藤主査】 そうですね。
【JAXA（久保田）】 御指摘ありがとうございます。
【佐藤主査】 細かいことですけど，やはりこのスタートラッカが，いかにも，せっかくあるのに，これほど機能しなかったのが，私の驚きでした。天文衛星だったからなのでしょうか，どうして全体の姿勢制御にこれほどスタートラッカが機能しないようなデザインになっているというのは，日本の天文衛星だけのことなのか，それとも世界的の衛星でも同じなのでしょうか。ヨーロッパとかアメリカの天文衛星も，全く同じような設計なのでしょうか。
【JAXA（久保田）】 スタートラッカにつきましては，最近は割と軽量化もできて，かなりいろいろな衛星で使われています。今回は天文衛星ということで，かなり精度要求が高くて，スタートラッカだけでは，やはりできなくて，IRUとのコンビネーションでやっていたということと，もう一つ，今回，スタートラッカは，最終的にはやはりチューニング不足だったというふうに考えておりまして，それがしっかりできていれば，スタートラッカも機能したと思うし，その途中の段階で起こってしまったのかなと思っています。
スタートラッカにつきましては，やはり放射線の影響ですとか，あるいはいろいろなところを見ますので，見た方向に明るい星が少ないと，やはり捕捉に時間が掛かるというのは今までもあったことですので，その辺のチューニング不足が一番大きかった。スタートラッカ自体，最近はいろいろな衛星で使われ始めていると思っております。
【佐藤主査】 今おっしゃった二つのことは，もう十分承知して分かっていることと思います。それについてのテクノロジーも設計も対応ができなかったということでしょうか。しかも，二つのスタートラッカが同じ方向しか向いてないとか，そういうの，私，ちょっと意外と思いました。細かなことですいません。
【白坂専門委員】 二つありまして，一つは野口委員におっしゃっていただいている。私と意見が違うわけではなくて，私も全く同じ意見です。
私もシステムで，設計で全部押さえるというよりは，設計だけではやっぱり駄目なので，総合力を出すために，設計はちゃんと伝えられるような設計をしてあげないと，検証側とか運用側ができない。さらに運用と検証とで押さえていくという，やっぱり3段構えでやるべきだという。
【野口専門委員】 分かりました。失礼しました。
【白坂専門委員】 いえ，とんでもないです。
あと，佐藤主査のスタートラッカの件ですが，今，普通の衛星は，もうみんなスタートラッカベースで普通に動いています。ただ，今回やっぱり，一つはすごく精度要求が高かったことと，新しいスタートラッカだったというのも，一つあるとは思ってまして，なので，そこも私は全体観だと思っているのですが，今回，新しいのを使っているから，じゃあ，どうしようというのを，もう少しうまくできているといいかなと思っていました。なので，検証のときの，しっかり，どれぐらいメーカーさんで検証して，そこの事象がどれぐらい設計に反映できていて，それが，運用の初期で想定外のことはやっぱり起きるので，起きたときに，それをどれぐらい重要視して，押さえ込んで，次に進んでいたかとか，そういう，今回の設計の流れからして，今回，新しいスタートラッカを使ったということが，どういう位置付けだったかというのは，これはケース・バイ・ケースですので，プロジェクトの人たちがどう考えて設計して，どう考えて運用したかというところ次第ですので，画一的には多分言えないと思うので，そこが複雑であればあるほど，設計の人が考えたことが分からなければ分からないほど，運用側はそれがちゃんと理解できず，運用で，本来ちゃんとやるべきだったことができてなくみたいな形にどうしてもなるので，そこはちょっとやっぱり一つ，私も新しいことをどんどんやっていかなければいけないと思っている科学者なんですけれども，新しいことをやらない方向に行くと，これはやっぱり本質的に逆になってしまうので，新しいことはどんどん挑戦しなきゃいけない。でも，挑戦するからこそ，設計もちゃんと考えて，その考えたことを，きちんと伝わる仕組みにしてあげて，検証でちゃんと押さえられ，さらに運用の人たちがちゃんと運用してくれるという流れを，新しいことに取り組める仕組みというのをJAXAは持っておかないと，JAXAさんが新しいことをやらないと，多分，日本の宇宙開発は，もう新しいところに行けなくなるので，そこを止めるのではない方向で，うまく根本原因を見付けていただいて，対処というのを考えていただければなというふうに思っています。
【JAXA（久保田）】 スタートラッカにつきましては，新しい開発品ということで，ASTRO－Hプロジェクトでも慎重に扱っていて，そういう意味では，ある意味，同じ方向に向けて，二つの答えがほぼ一致したら使いましょうという，そういう使い方と，スタートラッカでの姿勢決定値がIRUで持っていたものとずれてきたら，スタートラッカは，まず使わないという考えはあったんですけれども，一方，それの前提としては，IRUで，きちんと何日も姿勢が保持できるというのが前提なんですけれども，そこが一方，推定値を早くするために，一旦IRU誤差推定値を大きくしてしまったということとが整合しないんだと思っています。
【佐藤主査】 横山先生。
【横山臨時委員】 ありがとうございます。
関連してスタートラッカについて質問いたします。宇宙開発にはよく知られた枯れた技術を使うと伺いますが，スタートラッカは新しいものであったとのこと，ミッション要求に従って新しいものになったと理解してよいでしょうか。
また，カタログと照らし合わせて姿勢を制御するという役割は変わらないと思うのですが，どの部分が，今回，新しく採用されたものかを再度お教えいただけると，大変有り難く思います。
【JAXA（久保田）】 スタートラッカにつきましては，基本的なデータ処理は，カメラですので，星を撮像して，明るい星の相対的な位置とカタログとマッチングして，今，どっちを向いているかという基本的な原理は同じになります。
今回，ASTRO－Hで採用しましたのは，第3世代のスタートラッカと言われておりまして，計算機がかなり進んできますので，スタートラッカを持っているコンピュータで星の同定をしてマッチングするだけではなくて，そこから姿勢のデータを出すところまで行います。今まで第2世代までは，星の同定をしてカタログと一致したデータを地上に，姿勢制御系に渡すということを行っていましたので，姿勢データというよりも，星の位置情報とカタログとのマッチング情報を姿勢系に渡していたものから，今回の第3世代としては，姿勢の決定値，姿勢のデータまでを出すというような形になっています。
もう一つ，スタートラッカのデータというのは，カメラ画像を処理しますので，やはり処理に非常に時間が掛かっていて，前はデータが来るのに何秒も掛かっていたのですけれども，今回はスタートラッカは4ヘルツというふうに，1秒間に4回来るように高速になっています。そういう意味では，姿勢データを直接もらえるのと，それから計算速度が速くなって，データの来る速さが速くなって，姿勢の更新が早くできるという，そういうところがありました。それ以上にやはり姿勢の精度の要求も高いということもありまして，姿勢決定値を出して，なるべく頻繁にデータが来るようにというふうにして採用したものです。
実際には，スタートラッカの方は計算にミスがあったりということもあって，中にいろいろな機能があって，各種フラグを立てて，これが計算はしたけど怪しければフラグを立てるとか，いろんな自己機能を持っている第3世代スタートラッカを今回使ったというところで，今までとは機能としては，かなり高くなっているものを採用させていただきました。
【横山臨時委員】 ありがとうございます。大分理解が進みました。
私は科学と社会のコミュニケーションを専門にしていますが，この技術の審議というところに指名されましたのは，宇宙開発の技術について，素人の観点から，国民の皆さんが不思議に思うところをお伺いするということだと思います。
一連の御説明は，非常に真摯に，本当に率直に全てのことを出していただいたと感じています。また，研究者や協力メーカーも含めて，恐らく非常に真摯に対応されていることが，この一連の御説明からよく分かりました。そういう信頼がISASを中心に残って，ちゃんとあるということは喜ばしいことだと思いますので，非常に苦しいときだと思いますが，是非頑張って，この原因の究明を，しっかりと継続していただければというふうに思っている次第です。ありがとうございます。
【佐藤主査】委員の方々もおっしゃっていただきましたけど，これだけ原因究明のために，シミュレーションも含めて，進めていただき，明確に原因究明が進んだことはすばらしいことだと思います。
【木村主査代理】 すいません。ちょっと2点だけ。
1点は，先ほどの野口委員のコメントに，「そうだ，そうだ」というぐらいの意見なのですけれども。運用とか試験とか，特に運用なのですけれども，やっぱりトータルに考えないといけないと思います。先ほどのように扱うシステムがどんどん複雑になってくると，運用に対する要求が非常に強くなって，どう使うかというか，どう使ってほしいかということが，設計から出てくると思うのです。私も現場での開発についてある程度存じているのですけれども，なかなか衛星そのものが最先端で，すごくコストも人員も時間も掛かるということで，運用の仕組みの開発にまでなかなか踏み込めていないのかなと感じられます。そういう意味でいうと，運用システムについても増強していくというのは非常に重要なことだと私も思っています。特にヒューマンファクターであるとか，そういう部分というのは非常に重要なのではないか。今後，是非確認されたらいいかと思います。
あと，もう一点は，今の議論の中でちょっと思い出したのですけれども，お話の中で，「『すざく』の後継機として開発が進んできた」という表現がよく出てくるのですね。ただ，その一方で，運用上の要求もすごくきつくなって行く中で衛星がスケールアップされていって，恐らく初期の段階は，「すざく」をモデルにして設計の思想みたいなものが動いていたのだけれども，規模が大きくなることによって，ある段階から質的に変わっていって，開発する上での哲学が恐らく途中から変わらなきゃいけなかったのだと思います。そのことを十分意識されないまま開発が進んでいったことが，何かひずみを生んでしまったのではないかなと言うことが，すごく印象として強いのですね。その意味で，開発の過程での意思決定みたいなものが，どうされたのかなというのもちょっと気になります。そこでの判断とか，あるいはそれをみんなで共有できたのかどうかというところが，すごく気になるポイントです。恐らく同じように作っていけば，同じようなクオリティでいけるというのは，多分，スタートの段階ではよく思うのですけれども，最後は恐らく全く質の違うものを相手にしていたのかなと思われます。
【JAXA（久保田）】 今の点，御指摘のとおりで，原因究明していく中でも，最初，なるべく今までの技術を継承してということと，今回のミッション要求に基づいて変わるところということで，要所要所トレードオフはしていったのですけれども，だんだんそれを経るごとに，やはり今までのものと違うものができていったのに対して，トータル的な目で見ていたところが不足していたのかなと。要所要所の，ここを変えるか変えないかというトレードオフに関しては，各設計会議とか審査会で確認をしていったのですけれども，全体を見たシステムで，今までの別物ですというような観点では，御指摘のとおりかなというふうに考えています。
【佐藤主査】 繰り返しになりますけど，やはり今までのX線天文学のサクセスストーリーでいくと，研究者とメーカーが一体となって開発を進めて，互いに切磋琢磨してすばらしい成果を出してきたわけで，小さな衛星の段階では，少々のリスクを恐れずチャレンジして成果を出してきたと思うのですけどね。その精神は本当に大事ですけど，木村委員がおっしゃったように，これだけシステムが大きくなってくると，その精神は活かしながらも，全体のシステムの安全性を重んじることが必要で，このことは皆さんわかっていたにもかかわらず，結果的には弱かったのではないかと見えます。
今回のことに関しては，野口委員からもおっしゃっていただきましたように，ヒューマンエラーというのは起こるものだと必ず思って，それが起こったとしても，このような破滅的なことには絶対ならないように設計の段階からお考えはなかったのでしょうか。もちろん，こんな急激に自転して壊れた衛星は多分初めてでしょうか。対処できなかったかもしれないけど，危機的な状況に衛星がなったときに，特に姿勢制御系ですが，安定状態に強制的にもどすという発想はなかったのでしょうか。
【JAXA（久保田）】 衛星探査機の最初の設定の段階では，いわゆる致命的な事象に起こる要因というのを全部リストアップして，それについて対策を採ってきたわけですけれども，そういう考えで設計をしてきたわけですが，やはりトレードオフをして変えていく中で，そこでのもう一度見直しというのが抜けていたのかなというふうには考えています。
最初のときに，FMEAとか，いろいろな形で，こういう事象が起きると，これがどこに繋がるか，ここが壊れたら，どういう事象になるかというようなことを含めて，フォワード的に行うのと，あるいは致命的な事象が起こるには，どういう要因があるかと，両方で攻めた考え方に基づいて設計はしてきたはずなのですけれども，こういう事象になってしまって，やはり複雑になる中で見抜けなかったものがあったというふうには考えています。
【佐藤主査】 致命的なことが起こる要因として，自分で速く回転し過ぎて壊れるなんていうことは全くの想定外だったわけでしょうね。
【JAXA（久保田）】 想定に漏れていたのかと思います。
【佐藤主査】 漏れていたということですね。
とにかく何かのヒューマンエラーが起こるのは当たり前で，それに対して，ちゃんと対応し止める何かが必要だということです。
大体，きょうは事故の要因分析，その妥当性などに関しては，かなり議論はできたと思います。
野口先生。
【野口専門委員】 要因分析としては，このまま続けていただいて，有効な結果が出るのではないかと非常に期待しています。
ただ，先ほど主査がおっしゃったように，ちょっと気になっていることがあって，日本の場合はリスク評価というのが，ややもすると経験の整理になっている場合が多くて，そういう意味ではリスク分析と事故事例分析は違うということに気をつけていただきたい。だから，事故が起きるたびに，その原因を追及して，それに対処していくというやり方だと，常に新しいリスクには対応できないという構造があるわけで，そういう意味では，致命的な衛星の破壊ということに関しては，基本的にいうと熱か力しかないわけで，力というのも，力が発生する原因は外からくるとか，中から圧力が掛かるとか，若しくは角速度によってくる。そういう意味では，急速回転によってパドルが潰れるというのが事前に出てこないわけがない。リスクで考えてもです。ただ，それがそれまでのそういう事例がなかったということで，設計からは落ちていましたというのは，基本的に，物事の考え方がリスクべースで事前に抑え込むというより，FMEAとか，いろんなリスク分析をやっていることになっていても，それがやっぱり経験の整理にとどまっていたのではないかということの心配はあります。そういう意味で，そういう根本的な問題の見直しの可能性も含めてお願いします。
ただ，これは一朝一夕にいく話ではないので，僕がさっき言ったように，先端技術というのは，常にそういうものに対してチャレンジする仕組みがないと，新しいものは辞めるという方向性が出てくる心配があり，そのような姿勢では，これからの技術社会に適用できません。人間は1回手に入れた技術は捨てることはできませんから。やはり，いかにそれを有用に安全に使うかということの研究を並行して進めるしかないと思っています。そういう点も含めて，是非検討をよろしくお願いします。
【佐藤主査】 コメントありがとうございました。
ほかにはいかがでございましょうか。何か。はい，どうぞ。
【白坂専門委員】 今，説明の中で，設計段階でFMEA以外に，もう一つ上流側から，こういうのが発生したらみたいなのがあったのですけど，JAXA用語で想定FTAと呼ばれていると思うのですが，想定FTAは作っていたわけですか。
【JAXA（久保田）】 はい。たしか作っていたと。
【白坂専門委員】 なるほど。
今回の件は，野口先生がおっしゃったとおり，確かに分解という意味では，多分，漏れる可能性はあったかもしれないのですが，一方で姿勢がおかしくなるとかという，すごく普通のところでも押さえられていたはずなので，そういった意味では，そこで押さえ切れてなかったのが，ちょっと。私，想定FTA，作ってないのかなと正直思ったので，それはいかがでしょうか。
【JAXA（久保田）】 もう一度確認しますけど，致命的な事象から，どういう原因があるかというようなのもあって，回転速度というのもあったと思いますけど，多分，今までの経験から，リスクの評価としては起こらないことというようなことで，リスクの評価としては小さくなっていたんだというふうに考えています。
【白坂専門委員】 あと，野口先生がおっしゃったとおり，今回の事象について，きちんと背後要因までをやっていただけるといいかと思います。メカニズムとしては，すごく明確に分かってきたと思います。FTAを作っていたとしても，今回のように，ブロックできていた段階がたくさんあって，どこかで止まっていただろうなという気がします。なので，AND事象のところで多分止まるのが，普通の段階で作っていたらなっていたのが，本当はとまらなかった。つまり，その裏がやっぱりもっとあって，そこまで根本要因の識別ができると，この次に活きていく，すごくいいものになるかなと思います。FTAによる分析を途中で止めてしまうと，表面的な対策になってしまうと，やっぱり検証たくさんやりましょうとか，そういうのになると，シミュレータを作っても，今度，シミュレータのミスが発生して，シミュレータミスが起きないようにとか，ツールも1回しか使わないツールを大量に作って，全部検証してとかなると，やっぱり本質を外してしまうので，そこまでできれば，ちょっと時間掛かるかもしれませんけど，頑張っていただけると本質的な対応がとれて，新しいことをやっていく，これからのベースに活きるかなと思うので，是非，ちょっと大変かとは思いますが，やっていただければなと思います。
【JAXA（久保田）】 確認しますと，評価する中で，多分，セーフホールドというのを幾つか設けていて，そこで助けるような形だったし，スラスタがおかしくなったときには，もうワンセットありますので，そっちに切り換えて，そういうロジックで助かるという，そういう評価をしてきた。
【白坂専門委員】 はい。多分そうですね。設計上，多分，独立事象だと思って，起きないと思っていたものが，実はその裏にあるものが，何か大きなものがあって，それでAND事象が是非同時になくなってしまうというのをやろうとすると，多分，単なる設計の結果では駄目で，それを生み出した要因というところ，ちょっと大変なところではあるのですが，そこになってしまうのかなとは思います。
【佐藤主査】 ほか，よろしいでしょうか。
きょうはそういうことで，要因分析ということでございまして，JAXAの方から，本当に大変な努力のもとに，事故の経過，直接の原因の解明が進み，明確になっていると思います。御尽力に対して感謝したいと思います。
今後の対策とか改善事項などは議題にはございませんでしたので，次回の小委員会，5月31日で再発防止，今後の対策，その妥当性について検証を深めていきたいと思います。
JAXAにおかれましては，本日述べられました，いろんな御指摘コメントを，今後の検討作業に活かしていただければ有り難いと思っております。御説明どうもありがとうございました。
きょうの報告会は，これで終わりにしたいと思いますが，先生から，更に何かコメントはございますでしょうか。よろしいでしょうか。
それでは，事務局の方から，連絡事項等，お願いしたいと思います。
【事務局（奥野企画官）】 事務局より御連絡事項を申し上げます。
まず，会議資料，議事録の公開につきましては，宇宙開発利用部会同様，ホームページによって公開する方法をとらせていただきます。したがいまして，議事録につきましても，同様，ホームページの公開となりますので，あらかじめ内容等，御確認させていただきますので，御協力のほど，よろしくお願いいたします。
また，次回の開催につきましては，1週間後，予定してございます。詳細につきましては，事務方より委員の皆様に御案内申し上げる予定でございますので，よろしくお願いいたします。
【佐藤主査】 それでは，以上をもちまして，きょうの会議は終わりにしたいと思います。どうもありがとうございました。
以上
（説明者については敬称略）
研究開発局宇宙開発利用課