今後のHPCI計画推進のあり方に関する検討ワーキンググループ 産業利用アプリケーション検討サブワーキンググループ(第4回) 議事録

1.日時

平成25年9月30日(月曜日)14時30分~16時30分

2.場所

文部科学省 15階 15F1会議室

3.出席者

委員

加藤主査,秋山委員,天野委員,伊藤委員,奥野委員,笠委員,善甫委員,塩原委員,常行委員,吉村委員,渡邉委員

文部科学省

下間参事官,川口計算科学技術推進室長,遠藤参事官補佐

4.議事録

(1)国やソフトウェアベンダの支援の在り方について及び報告書取りまとめ

 川口計算科学技術推進室長より資料1に基づいて説明。意見交換は以下のとおり。

【加藤主査】  報告書を最終版にすべくいろいろ意見交換をこれからしていきたいと思うのですが,章ごとに分けて確認したいと思います。まず,序章はいかがですか。
【秋山委員】  この報告書にはシミュレーションのことしか書いていないです。確かに大規模なものの9割以上はシミュレーションだと思いますけれども,私が所属している分野では非常に大型の統計解析のようなこともやっています。この産業利用アプリケーション検討サブワーキンググループで議論されるメインがシミュレーションかもしれませんが,シミュレーションしか扱わないのかということを確認します。
【加藤主査】  私の頭にあったメインはシミュレーションです。データ解析という観点では,シミュレーションが大規模化することによって,例えばプリ処理やポスト処理のデータ解析が大変になって,そのための共通基盤的な技術開発が必要であるという記載は入れています。シミュレーションを抜きにしたデータ解析に関しては強い意見があれば報告書に入れますが,いかがでしょうか。
【秋山委員】  メインはシミュレーションということでよいと思います。意見として申し述べさせていただきましたので,ここだというところを見付けられましたら記載いただくよう御配慮いただければと思います。
【加藤主査】  そうですね。ビッグデータに少し関して議論して,とって付けたような記載をするよりも,ビッグデータの解析や統計処理の新たなアプリケーション分野として,別に議論してまとめた方がよいと思います。
【秋山委員】  お任せします。
【加藤主査】  次に,第1章に移りたいと思いますが,いかがですか。
【塩原委員】  1.2の第1パラグラフで「創薬ストリーミング等のバルクジョブを利用した実証研究においては得られた成果」は「直ちに実用化される」という可能性があることを書いていますが,特に創薬の場合は,いいものが計算上得られても,実際物を合成して,動物実験,臨床試験を行って10年先に実用化ですから,これは「直ちに実用化に向けた開発段階に移行する」とする方がよいと思います。
【加藤主査】  実用化という意味が上市という意味でとられたらそうですが,ここに書いてある意味は,あくまでもその成果が使われるということです。つまり,HPCIの産業利用は基本的にはテストするための環境を提供するためのものだけど,創薬スクリーニング等のバルクジョブを利用した実証研究では,その実証研究の成果が使われるという意味で実用化という言葉を採用しました。ただし,薬がすぐできてしまうととらえられてもよくないですね。
【塩原委員】  「直ちに実用化に向けた開発フェーズに移行」ということではいかがですか。
【秋山委員】  実用化というのはアプリケーションの実用化ですから,元の通りでよいと思います。
【加藤主査】  ここの実用化というのは,この成果が直接製品に使われると言う意味です。
【秋山委員】  いやいや,そこで言うプロダクションというのは,製剤じゃなくて,リード化合物で構わないのですよね。
【塩原委員】  ここがリード化合物という意味であれば,それは実用化に向けた一つということでよいと思います。
【加藤主査】  いや,分かっているつもりですが,どう書き換えるかだけです。得られた成果から直ちに実用化研究につながることも期待されるというような書き方でどうでしょうか。
【渡邊委員】  創薬に限らず,例えば自動車でもそうですけれども,最後は実際にやってみないとわからないわけです。製品化に必要な情報のうち,7,8割ぐらいのところまでは計算機でわかる。その残りの部分は実際にぶつけてみないと分からないという意味だとしたら,僕はこのままでいいと思っています。
【加藤主査】  誤解されているみたいですが,数年後の実用化とあります。この場合の実用化というのはソフトウェアを実用的に実務で使うという意味です。それに対して今の議論は,バルクジョブによる実証研究では,いいもの(製品)ができることもあります,という意味です。
【渡邊委員】  その意味で僕はこのままでもいいと思います。
【加藤主査】  車でも,例えばバルクジョブをやれば,それがそのまま実用化につながるということもある。創薬と書いたから,実用化につながるというと誤解を受けるので,単純に「創薬スクリーニング等の」を逆に削除してしまって,それ以降をそのままにすればいいのではないでしょうか。
 それから,すぐれたリーディングマシンを開発するということは実証研究をリードすることにもなって,それは産業利用のためにも非常に意味があるという記載を追加していますけれども,そこはよろしいですか。
【吉村委員】  リーディングマシンのハードウェアとその上できっちり動くアプリケーションが,対にならないと実際の産業利用にならないという構造があるとすると,リーディングマシンを日本が持っていないと,そういう環境で動くようなアプリケーションが開発できない。そうすると,全てが成立しないということだと思っています。ですので,そこが明確に書かれていないような気がします。
【加藤主査】  今の書きぶりだと,1.2の最後のパラグラフでリーディングマシンの能力を向上させることは実証研究の高度化につながり,それは数年後に実用化されるアプリケーションの高度化を通じて産業競争力の強化になるとありますが,なくてはならないというニュアンスではないですね。
【吉村委員】  産業利用ということを考えると,より重要なのはアプリケーションがあって,そのアプリケーションを支える技術としてリーディングマシンがあるという関係でしか産業利用にはならないような気がします。それが,この書きぶりだと,リーディングマシンさえ開発すれば,そのうちにその上で動くアプリケーションというのはもしかしたらうまく出てきて,それが結果的には産業利用につながるでしょうというような形なので,もっと産業利用とかといった目的となるイノベーションを出すために,そのようなアプリケーションは絶対必要だということがわからないと思います。
【加藤主査】  分かりました。リーディングマシンを向上させれば実証研究が高度化されて,実用化されるアプリケーションも高度化されるから,競争力強化につながるというように,リーディングマシンから書き始めているからいけないのですね。
【吉村委員】  産業利用という観点からすると逆ではないかなと思います。
【加藤主査】  産業競争力強化のためにはアプリケーションの高度化が必須であって,そのためには実証研究する場としてリーディングマシンの開発が必須である,というように書き換えます。
 第2章に進みたいと思います
【秋山委員】  第2章では国プロアプリとオープンソースは全く直交するものとして書かれています。現状を語っているところでは何の違和感もないのですけれども,このあと国の支援の在り方とかを議論するときに,オープンな形で開発するものと,国プロアプリというものがずっと直交していくというように感じられて,違和感になってしまいます。
【加藤主査】  私の理解は,直交するというよりは,むしろ並行というイメージですね。研究開発あるいは実証研究フェーズにあるものとしてオープンソースコミュニティで開発されているものもあるし,国プロの主導で開発されているものもあって,国プロで開発された成果がコミュニティを作ることによってオープンソース化することもあって,更にそれが事業化されて市販化されることもある。ただ,そのオリジンが違うということです。
【秋山委員】  国プロと呼ばれているものも大体中核の先生がいらっしゃって,コミュニティですよね。加藤先生の御説明は分かったのですけれども,この文章だと本当に世界を3つに割っているだけに見えてしまいます。第2章で話すには早かったかもしれません。
【加藤主査】  この点は第3章で話しましょう。
【吉村委員】  スパコンによるシミュレーションと実験の比率がものづくりの中で変わってきていると思います。もちろん実験を全くしないで,衝突シミュレーションだけで自動車会社が物を作れるかということは,技術の問題だけではなくて,社会がそれを受け入れるかどうかということと絡むのですが,設計解に当たるものを導出するプロセスをどんどんシミュレーションに置き換えていって,最後にそれを確認のために実験をやるというように,現状と今後はその比率が明らかに変わっていくのだと思うのですが,そのことが余り書かれていないと思います。
【加藤主査】  そういう認識はもちろんあります。第1章のところに総論的な話としてシミュレーションの重要性が増しているということは書いたつもりです。定量的にどれぐらい実験がシミュレーションに置き換えられるかとかいうと,それは場合によるので,もし今のようなことを書くのであれば,序章の方がいいかとは思います。
【吉村委員】  なぜそれを言ったかというと,将来展望に関連して,特にエクサスケール時代という話になると,その方向に行くかなと思ったからです。
【加藤主査】  分かりました。定性的にシミュレーションの重要性が更に増し,場合によってはシミュレーションだけでも物ができるということを入れましょう。
 それでは,第3章に移りたいと思うのですが,いかがですか。
【伊藤委員】  2点あります。1つは3.1の第2パラグラフのピーク性能が出なくなりますという話ですが,これはそのとおりだと思うのですが,具体的に1~5%と書き込んでいることが妙にとられないかというのが心配です。
【加藤主査】  専門家にとっては全然違和感のない数字だと思います。
【伊藤委員】  違和感はないのですが,1%のためのマシンを開発するのかと言われかねない,というのが心配だということです。
 3.1の最後に,プリ・ポスト処理,可視化機能が重要である。それから,第3章の終わりに中長期的なところにそれが必要であるというような書き方をされているのですが,この必要であるということは,当然それも含めて開発すべきであるという意味だと思いますが,もう半歩ぐらい踏み込んで書いてもよいのではないかと思います。
【加藤主査】  この報告書全体のスタンスは,第1章で全体的な前提事項みたいなことを書いて,第2章で将来展望して,第3章でアプリケーションの開発動向,開発計画を書いて,そこは課題までしか書いていません。こういうことをすべき,ということは第4章に持っていっているので,もし必要があれば,第4章に書くということにしています。
【伊藤委員】  分かりました。
【加藤主査】  先ほどの1%~5%なんていう数字を書いていいかという話はどうでしょうか。これは,全部が全部ではなくて,例えばMD(分子動力学)シミュレーションなどでは20%ぐらいまでいきますが,熱流体構造解析では原理的にそう(1%~5%に)なります。10%も20%も出るような印象を持たれ続けるよりは,現実的にこうなっているということを明記してしまった方がいいと思っています。文部科学省の立場としてはどうですか。
【遠藤参事官補佐】  ここの記載というのは,今のままでいけばこうなるけれど,それを改善するために,例えばテストベッドを用意するとか,いろいろな研究開発を行うということだと思うのですが。
【加藤主査】  私の中で想定しているのは,テストベッドですごく頑張って5%にしかならないということです。それはハード面の性能と現象の支配方程式の基本的な特性とで決まってしまう。だから,あんまりそこに期待感を持たれるような書きぶりはかえってミスリーディングになると思います。もし懸念があれば,何も書かないという手もありますが。
【伊藤委員】  わざわざ書く必要がないということを言いたいです。
【加藤主査】  僕がここで言いたかったのは,すごく難しいから,こういう状況の中でどうやって開発していくのか,という認識を持ってもらうために1%~5%と書いたのですが,どうしましょうか。
【伊藤委員】  ピーク性能を出させるのは難しいではいけないでしょうか。
【吉村委員】  国内の産業利用の1つの大きな分野として熱流体構造解析分野が出てきているのですけれども,確かに,ピーク性能1%~5%程度ということだったら,ピーク性能が100分の1のマシンで数十%の効率のアプリケーションを開発する方が得ですねというような議論に行く可能性はあると思います。もしかしたらこれを超えるようなものにチャレンジするところも出てくるのではないかという気もするので,あえてここだけ入れる必要はないかなという感じはします。
【加藤主査】  実は,マトリックス等を全部再計算すれば,ピーク性能比だけは20%ぐらいまで上がりますが,現実的には余り速くならない。だから,実用的にはという意味で書いています。
【秋山委員】  私は,このまま載せた方がいいと思っています。変えるとしたら,限界という2文字変えればよいのではないかと思います。
【加藤主査】  難しいと書きますか。
【秋山委員】  数字はこのままの方がいい。
【加藤主査】  分かりました。書きぶりを変えましょう。
【秋山委員】  その辺の目標だと。それをはるかに超えることはあるかもしれないけれども,限界と書いちゃうと本当に上限というイメージがしてしまいします。
【吉村委員】  限界というと,やっぱり理論的な限界というふうな,絶対超えられないというふうにとられるわけです。
【加藤主査】  実は私としてはそういう意味で書いたつもりですが。分かりました。
【秋山委員】  そのぐらいしか得られないだろうと予想されるとか,ちょっとやわらかい方が良いと思います。
【遠藤参事官補佐】  「現状のままではピーク性能比で数%程度の計算速度にとどまってしまう」でしょうか。
【加藤主査】  「現状のままではピーク性能比1%~5%の計算速度にとどまってしまうことが危惧される」という言い方ですかね。後で書きぶりは調整します。
【渡邊委員】  理論的にこのあたりに実際なってしまいますね。
【加藤主査】  ハードを知っている人は違和感がない数字だと思います。
【吉村委員】  先ほど言いましたように,いろいろな分野を考えたときにこのレベルのリーディングマシンが不要ですということでは全然ないですけれども,少なくとも特定分野の産業利用ということを念頭に置くのであれば,このマシンが適切であるとは言えない,となる可能性があると思いますし,そこまで断定できるかなということが懸念されます。
【加藤主査】  いずれにしても,適宜修正をします。
 ほかの点はいかがでしょうか。特に,伊藤さんから3.4節の最後に,オープンソース・ソフトウェアに関して,もうちょっと積極的な支援策を検討すべきではないかという話がありましたが,ここでは事実だけを書いてあるということです。その点が国プロアプリとオープンソース・ソフトウェアの明確な違いだと思います。それがさっきの秋山さんの直交か並行かという御質問に対する答えにもなる。その明確な違いがあるから,それを直交だと言えば直交ですが,ねらっている方向は同じという意味では並行になるということです。
【吉村委員】  ここで言っているオープンソースというのが,限定された定義で書かれているところが気になっています。実際のオープンソースというのは,国プロアプリのように,物すごくバリエーションがあると思います。
【加藤主査】  確かに,ソースをオープンにしてだれでも使えるという形にしているので,イノベーション基盤シミュレーションソフトウェアの研究開発プロジェクトで開発されたものもオープンソースですね。そういう違和感があるということは分かります。秋山さんが言っていた違和感は,そういう違和感でよいですか。
【秋山委員】  そうです。この分類を放棄する必要はないと思うので,OSSの中から国プロも拾い上げられてくるし,そこは行ったり来たりするということが読者に分かるように書かれていればそれでよいかもしれません。
【加藤主査】  報告書の頭のところに,ここで言っているオープンソースというのは,国等プロジェクトで開発された以外のソースをオープンにしているアプリケーションというように,定義を書いておくようにします。
【常行委員】  オープンソースという言葉が最初に出てくるのは序章の最後のパラグラフです。
【加藤主査】  ここに入れますかね。
【吉村委員】  市販ソフトと国プロ,あるいはここで言っているオープンソースとの間に明確なラインがあって,市販ソフトはソースそのものがクローズなわけです。クローズなので,それをいじれる人間というのは,それのベンダしかない。それに対して国プロソフトにしてもオープンソースと言っているものにしても,ソフトそのものにアクセス可能なので,新しく出てくるリーディングマシンに対してもいろいろ対応でき,機能を追加できるという意味で,ある種の自由さがあると思います。そこの部分のニュアンスは書いてありますけれども,国プロとオープンソースとの間の共通する部分についての意義みたいなところというのが見えなくなっているところがあるので,オープンソースが何であるということを明記するのと同時に,ソースがアクセス可能であるという利点をどこかに書いていただくといいかなと思いました。
【秋山委員】  済みません。市販のソフトウェアの中でもソース,若しくは中間言語で書かれていたりして,読めて,変更できるものが,我々の分野ではあります。ですので,そこは明確な区別だと私は思っていませんでした。きちっとビジネスモデルがあって,商売にされているかどうか,保証があるかということだと思います。
【加藤主査】  商売されていると言う分類だと,OpenFOAMなどラッパー(インターフェース)が商売になっている例もありますから,そういう分類もなかなか難しいと思います。
【秋山委員】  オープンかクローズかでというのは,ソースが見られるかどうかということになると思うのですが。
【加藤主査】  例えば,Gaussianの商用版は公開されていますか。
【善甫委員】  公開されています。
【伊藤委員】  ソースで買えばソースが読めます。
【善甫委員】  手を加えたら,元へ戻さないといけない。
【加藤主査】  それはGPLという意味ですか。
【塩原委員】  報告義務はないので,自分の目的ではいいのではないかと思います。
【吉村委員】  分かりました。私は構造関係とか流体関係のCAEを念頭に発言しました。
【加藤主査】  いずれにしても最初に出た国プロアプリもオープンソースではないかと言われればそれはそうなので,ここで言っているオープンソースの定義を書くようにします。
【秋山委員】  少しずつ重なり合っているけれども,分かるでしょうということで,書いていただければいいと思います。違和感の一番の理由は,第3章の終わりにオープンソースは国が主導することは難しいと書かれていることが,何となく見放していると感じたものですから,そこはダイナミックに行ったり来たりするという方が正しいのではないかなと私は感じています。
【加藤主査】  分かりました。
 第4章に進みたいと思います。
【伊藤委員】  商用ソフトにしても,国プロソフトにしても,産業界が使うというのは,長期にわたる可能性が高く,ハードウェアの更新サイクルの方が短いと思います。ハードウェアの人は,その新しいマシンに合うようにソフトウェアを作り変えろというのですけれども,それは難しい。ですので,8割か9割ぐらいの能力を出してくれるようなインターフェイスを考えるということをどこかで一言入れてほしいと思っています。
【加藤主査】  そういうリクエストはあったのですが,例えば「京」とか,ポスト「京」を作るのであれば,それが(同じような計算機が)産業界に広まるようにしてくれないと,こういうベンチマーク環境を作っても意味がないですよということを,直接的なリクエストとして書きました。それに対して,伊藤さんが言っているのは,「京」や,ポスト「京」にチューニングしたものが,それが実際に実用化されるときに使われる計算機のエミュレータというかそういう環境を用意してくださいというふうに聞こえますが,そういうことでよいですか。
【伊藤委員】  基本的には両方必要だと思っています。当然親和性が高いアーキテクチャになれば,産業界側では非常に有り難いけれども,多分ポストポスト「京」がポスト「京」とほぼ同じアーキテクチャでいくのは厳しいのではないかと思っています。そのときに,やはりソフトウェア的に吸収できるものを用意しておく必要がある。ハードウェア側の用意なのか,ソフトウェア側の用意なのか,分かりませんが,それがないとなかなか産業利用というのにつながらないのではないかと思います。
【加藤主査】  報告案では,リーディングマシンがアカデミアに使われるだけではなくて,きちんと産業界でも売れるようにしないと駄目ですよという書きぶりです。伊藤さんが言っているのは,そこまではいかなくて,アーキテクチャ的に実際に使われるアーキテクチャと違ってもいいから,ソフト的に何とかしてくださいという意味ですか。
【伊藤委員】  ここで書いてあることは非常にいいと思っていますが,それに加えてという意味です。
【加藤主査】  書くとすると,アーキテクチャの類似性を担保することが重要だけれども,それが担保されないときのためにエミュレータ的な環境も用意してほしいという書きぶりになると思います。もっと直接的に言うと,今「京」でチューニングしているアプリケーションがそのままIntelのXeon Phiでも動くようにできるものも用意するべきだというリクエストを出すということになります。
【伊藤委員】  現状では多分Xeon Phiなどで動くようなものにしていただいた方が産業界にとってはよいと思います。これが7年先に状況が大きく変わるかどうかはよくわからないので,ソフトウェアによる担保が必要ではないかと思います。
【加藤主査】  私はそこに論理的な矛盾があると思っていて,原案に書いてあることがきちんとできたらエミュレータは要らないと思います。つまり,リーディングマシンが世界中に広まっていけば,それがメインストリームになるわけで,そこで実証研究し,最適化したものは全部そのまま使われる。ただし,そうならない可能性もあるから,そのときのためにエミュレータ的なものの開発も要求する,という論理になると思います。
【伊藤委員】  違う感じがしていて,今までの計算機の歴史を見ると,必ずしもアーキテクチャ1本で来なかったし,多分1本でいかないという方が妥当だと思います。1本でいかないとすると,リーディングマシンができて,その時代から数年の間に産業界に展開するようなもののアーキテクチャがアプリケーションに対して親和性を持ってほしいというのはいいと思います。ただし,その先になると,アーキテクチャは大きく変わるわけです。だけど,ソフトウェアの命って,多分20年ぐらいある。そうすると,20年あるものに対してどう対応するかという書きぶりは必要ではないかという意味です。
【加藤主査】  分かりました。その時点ではなくて,アプリケーションの寿命が長いことをちゃんと認識して書くということですね。
【伊藤委員】  そういう意味です。
【加藤主査】  今書いてあることを置き換えるわけではなくて,ハードウェア開発者は,あるいはシステム開発者はエミュレータ等を適宜提供すべきだということを加えるということにします。
 ライセンスの問題はどうですか。これは自然に解決されるという書き方をしていますが。
【秋山委員】  HPCってもうかる業界なのでしょうか。私のイメージは,間違ったことを言うかもしれませんけど,例えば介護関係の機器がもっと開発されるべきだけれど,今すぐ参入してもペイしないとか,省エネを進めないといけないけれども,補助金を出さないと,企業がそっち関係の新製品を出さないとかいうときに,政府が補助する。マーケットに任せると言っていて動くような規模の分野ではなく,ライセンス料の問題は非常に大きな足かせになると思っているので,何か支援するという議論もあるという,両論併記ぐらいに残してもらえることを個人的には希望します。
【加藤主査】  分かりました。
その前に先ほどの伊藤さんの御意見の確認ですが,ポイントとしては,産業利用アプリは,普通のアカデミアで使われるアプリよりも寿命が長いと考えているということでよいですか。
【伊藤委員】  そこです。
【加藤主査】  寿命が長いというのは1回使い始めたら簡単に手放さないから,ポスト「京」の次を開発するときに,ポスト「京」にいろいろチューニングしたアプリが使えるようにしてくださいねという話になると思います。
【伊藤委員】  そうですけども,そうすると7年先まで何もやらぬということになっていて,今でも「京」でいろいろやらないといけないですよね。
【加藤主査】  例えば今「京」でチューニングしているものを,ポスト「京」でもが動くようにしてくださいね,という意味ですよね。
【伊藤委員】  そういうことです。
【加藤主査】  先ほどの,ライセンス料の問題を国が主導で解決すべきか,あるいは国が解決の主導をすべきか,という議論に戻ります。
【吉村委員】  市販アプリケーションのほとんどの場合,グローバルマーケットで使われているものなので,日本国内の特定のマシンとの関係だけでライセンス料について補助金を出すというのでは,変わらないと思います。一方で,ある会社が並列マシンに対するラインセンス料の考え方を変えたならば,そちらに一斉になびくと思われますので,今ここに書いてあるとおりのままでよいのではないかなという感じがします。
【秋山委員】  反論すると,やり方は議論すればいいと思いますが,例えば補助金という形にすれば,買った人に対してお金を戻すことができるので,売っている会社のビジネスとは関係なくできると思います。客観的に放っておいて大丈夫かということが心配です。
【加藤主査】  あくまでもコストを低減するための施策は打ち,それから,ニーズを増大させるための施策も打って,コストが低減し,ニーズが多くなってくれば自然にライセンス料は下がる,というのが今の論理です。
【秋山委員】  どういう政策を打つのですか。
【加藤主査】  テストベッド環境を提供して,その技術的支援を付けるということが明記されています。
【秋山委員】  売る側から見ると,100倍使うなら,何倍払えのヒジネスモデルから脱却するインセンティブは何もないと思います。
【加藤主査】  インセンティブがニーズで,ニーズというのはお金です。国がお金を払わなくても,ユーザがお金を払えばいいわけです。例えば,今の100倍のユーザが使うから,そのかわり今のコア数の1,000倍使わせてくれというとしたら,入るお金は100倍になるわけです。つまり,ニーズを増やすためにいろいろ実証研究をやっているわけです。こういうことができるという流れが,全体的な考え方です。それに対して,もうちょっと直接的なインセンティブを付けるべきだということですか。
【秋山委員】  結果としてこういう紙が出ても,今までどおりのことをやるということしか書いてないとインパクトがないので,幾つか新しいアイデアを入れられたら,ここで議論したかいがあるのではないかなと思います。マーケットがこれから大きくなるというのであれば今のお話でいいのですけれども,特定のことはしなくて大丈夫なのですか。
【笠委員】  ある種の市場というのはあると考えていまして,特に流体解析や構造解析の分野ですと,使われているソフトウェアが二,三あって,それぞれを企業としては使いこなそうとしています。それは市場原理に任せて,1つのソフトウェアにかけると,場合によってはソフトウェアがなくなるということもあり得ているので,複数のものに手を掛けますし,複数のものにライセンス料を払うというようなことをやっています。これは裏を返すと,我々自身が市場原理を働かせようとしているということです。それをあるリーディングマシンなりを考えたときに,そこに手を加えていただくかというのは,企業から見ても少しいびつな感じがしてしまいます。
【加藤主査】  議論の観点が少しだけずれているのですが,ここでは高並列化された計算が,一般に産業界で使えるようなものができてもライセンスの問題は残るので,そのときに国として何かすべきか,あるいはマーケット原理に任せておけばいいかという議論をしていますが,それに対してはどのようにお考えでしょうか。
【笠委員】  それに対しては,市場原理に任せるというので解決できると思います。
【加藤主査】  ほかに秋山さんのおっしゃっているような御意見がありますか。なければ,議事録には残しますが,その御意見は却下させていただいて,報告書としては今のままにしたいと思いますが,よろしいですか。
【秋山委員】  私が言いたいのは,施策のことをここに書いてくださいということよりは,放っておいたらば,ハードウェアの進歩を産業応用として使い切れないと心配をしているということです。問題があると書いておいてもらえば,それだけでも結構です。
【加藤主査】  それでは,放っておいてもできると思われるけれども,これを一層加速するための検討も必要である,という書きぶりにしましょう。
 では,国プロアプリのところに移りたいと思います。
【塩原委員】  ユーザコミュニティができるのが一番いいと思うのですが,開発も含め,継続的に運用するのは大変だと思います。国プロアプリを見ていると,情報の伝達が余りうまくいってないのかなという気がします。例えば更新履歴を見ても,幾つかの不具合を対応したというぐらいで,何をどう直したのかよく分からないです。国プロアプリはバグを見付けたら報告することになっていますけど,本当にバグ情報が集まっているのかは疑問です。一方で,商用ソフトの場合,利用者はベンダに言って直させるとか,いつまでに直るのかというようなプレッシャーを掛けるとかで,それでバグが減っていくということがあると思います。ですから,ユーザコミュニティは重要ですけれども,まず情報をちゃんと吸い上げる取り組み,あるいはもらった情報をフィードバックする取り組みについても入れていただければと思います。
【加藤主査】  それは,4.3の第3パラグラフにある「そのため,国は,国プロ開発アプリケーションについて,画期的・先導的な機能を重視して計画的な開発を行う」と,次のパラグラフの「とともに,使いやすくするための機能の導入,ユーザサポート体制の構築,継続的な維持・管理などの利用支援を充実させることで」というところの言外の意味として一応書いたつもりです。ただ,明確に伝わらないということであれば修正しようと思います。
 ユーザコミュニティを形成することについてはいかがですか。国が維持管理機能を担う拠点を作るだけではなくて,きちんとコミュニティも作って,ソフトウェアを育てる責務があり,最終的にはそれが商用化されるべきであるというところまではよいのですが,コミュニティを直接支援するとなると,まして,オープンソースに対してのコミュニティの支援となると,何をやるのかは難しいと思います。
【伊藤委員】  私はコミュニティの活動に国がまず支援すべきと主張しましたけれども,永続的にやることを想定は全然していなくて,ユーザコミュニティが立ち上がるところまでは何らかの措置が要るのではないかと考えています。
【加藤主査】  立ち上げ支援でしょうか。
【伊藤委員】  そういうことだと思います。永続的にやってしまうと,それはコミュニティではないと思います。
【加藤主査】  そうすると,例えばそのための会議を開催するという話になるでしょうか。
【吉村委員】  国プロでも市販アプリでも,基本的にソフトウェアを作って,それを維持管理するのにかなりの人的な労力が必要なわけです。いろいろ問合せがあっても対応できないのは,開発するまではきちんと人も付き,お金も付き,研究員も付きという形でやっているのに,それが終わった途端にそういう人がいなくなるからです。例えばADVENTUREの場合ですと,研究グループを維持していますけれども,全員ほとんどボランティアで,低コストで作っているので,いろいろなことが動くのですけれども,国プロアプリの場合には,開発も100%でできるということはなくて,ずっと開発が続く中で,維持もする。そのために必要な体制をどのレベルで国が作るべきか,ということは悩ましいところで,やり過ぎると本来だったら自立できないソフトを延命させることになるという場合もあります。その部分をどのように書くかというのは難しいなと思っているところです。
【加藤主査】  戦略プログラム分野4では,そういう運用を既に始めていて,サポートのための新たなサイトの立ち上げや,機能強化の支援を産業界の声をきいてやっています。おっしゃるように,そのままいくと死んでしまって,あるいは生かしていても役に立たないようなソフトに税金をつぎ込み続けるということはよくない。ただし,それを明確に書くと,国プロ開発アプリの全てが生き残るわけではないので,アプリケーションを選択して,支援していくための拠点を形成するという書きぶりになりますが,いかがですか。
【伊藤委員】  作ったソフトウェアの全部が産業界で使われるとは限らないですが,使われないソフトウェアに対しても,コミュニティができ上がるまでずっと国が立ち上げ支援すると,カンフル剤打ちっ放しということになるので,選択して,あるところで見極めをしていくことが重要だと思います。
【加藤主査】  それを直接的な書き方をすれば,今後,広範囲な分野,あるいは多数のユーザの産業利用が見込まれるソフトウェアに限って,それを維持管理するための拠点を形成するとなりますが,それでいいですか。
【渡邊委員】  そのとおりだと思いますけど,ただ,拠点を作っても,そこに財政的な支援がない限り,維持管理していくのは絶対無理だと思います。
【加藤主査】  それは,基盤的なソフトウェアの研究開発だけではなくて,本当に使われるものは維持管理していこうということを検討はしています。それがソフトウェア開発の1つの柱にしようということで検討は進めていますので,精神というか,それは引き継がれると思います。
【渡邊委員】  維持というのは本当にお金が要ります。人件費が掛かるわけです。
【加藤主査】  分かります。でも,それはHPCIで協力して,きちっとしたハードウェアプラットフォームを作っていきますというのと同じぐらいの重みで精神を引き継いでいけばと思います。
【渡邊委員】  精神論だけでは駄目だと思います。
【吉村委員】  明らかに欠けているのは,例えば5年間プロジェクトをやったあとの維持管理をするのに必要な競争的な研究資金の獲得する方法です。前回,ADVENTUREの開発はいろいろなプロジェクトをつないでいったということを述べましたけれども,あの中にどれ1つとして,ADVENTUREというものを作ったから,それを維持管理するのにお金をくださいと言ってくれたものはありません。別の,特にアプリケーションを意識した提案をして,それをとっていた。そういう意味では,競争的研究資金でよいと思いますけれども,国プロアプリを開発したら,それをある条件,ある評価の下で維持管理するということが必要だと感じています。
【加藤主査】  分かりました。お金がなければ拠点だけ作ってもしようがないというように,そしてきちっと評価した上で維持管理するというように書きぶりに変えます。
【渡邊委員】  それは吉村先生がおっしゃったように,競争的資金にして,そこで評価して,これは本当に伸ばすべきかどうかという判断をすればよいと思います。
【加藤主査】  ただ,もう少し違うニュアンスもあって,競争的資金にして維持管理のお金を付けるというのは,その特定のプロジェクトに対して維持管理のためのお金を更に付けるという意味です。
【渡邊委員】  特定のプロジェクトよりも特定の成果物ですね。
【加藤主査】  ここで書いてあるのは,例えばユーザが国産で開発されたいろいろなアプリケーション,特に産業利用できるものはどこにあるということがすぐ分かるようなサイトも含めて,そういった拠点を作ろうというもう一つの意味があります。実は,既に戦略プログラム分野4でこのようなサイトはほぼできて,10月には公開するんですが,それはいいですよね。
【渡邊委員】  もちろん。
【加藤主査】  改良するのは開発者ですけれども,サイトとしては,あるいは拠点としては何か1個バーチャルな,オールジャパン的な拠点があるというのはよいですか。
【渡邊委員】  はい。
【加藤主査】  分かりました。競争的資金や,評価の上でという,そういうニュアンスを付け加えるということにしましょう。
【笠委員】  ユーザコミュニティに何らかのインセンティブを施策として与えるというようなことを盛り込めないのかなと思います。セレクトして取り扱うアプリケーションが決まったとして,競争的資金でいいので,そういうソフトウェアをトライアルで使えるという環境をコミュニティに投げ,そこに人が集まるような施策というのは,できないかなと思います。戦略プログラム分野4ではかなりやられていることのような気もしますが。
【加藤主査】  市販アプリというのは動きさえすれば,きちんと解析ができることが分かっているので,チューニングして性能を出すとか,大規模な解析ができることを検証するためのテストベッドを提供する。一方,国プロアプリとか,オープンソースというのは,動いたときにどれだけの効果が出るか分からないから,それを検証するための環境をコミュニティに提供するという御意見でいいですね。
【笠委員】  はい。
【加藤主査】  いいのですが,コミュニティに提供するということに違和感があります。
【笠委員】  コミュニティにというのはちょっとですね。
【加藤主査】  コミュニティに属する人がそのコミュニティで開放されているOSSなり国プロアプリを使って,こういうことをやりたいといったときに,それができる環境を提供するということは既に書いてあるという整理になると思います。これは,ずっとコミュニティを支援するのかということとは違う話なので,立ち上げの支援をするという整理でいいですね。
【笠委員】  既にあるのですが,セレクトすると言っていた部分に関連して,何かインセンティブを付けられないかということです。
【加藤主査】  コミュニティに対しては,そんなに国が口を出すものではないと思います。例えばイノベーション基盤シミュレーションソフトウェアの研究開発プロジェクトで開発したソフトウェアに対しても,国が主導的にやるコミュニティと,自分たちのコミュニティでやりたいというものもある。後者に関して,側方支援はいいのですが,あんまりそれで取捨選別されたくないというマインドが強いです。だから,それに対してコミュニティの順位付けまで国がやるということに対しては多少違和感がありますが,ほかの方はいかがですか。
【吉村委員】  実はコミュニティという言葉に若干違和感を持っているのですが,例えばソフトを公開すれば,一般のユーザが使いたいとどんどん来て,そこの中でいろいろ話が進むわけです。特にソフトの開発フェーズからある程度いろいろ使えるようになると,それを使って実証フェーズを,オープンのユーザとやるということがあるので,コミュニティというのは比較的顔が見えている人たちということですけど,それ以外にも実はあるわけです。先ほどの維持管理の中に産業界のいろいろなユーザと実証解析をして,更に性能を高めていくとか,そういう活動も含めて考えれば,維持管理を結局サポートする,あるいはそれをちゃんと評価し,セレクトしながらやるという中で,その1つの活動としてうまく入れられるのかなという感じはちょっとしました。
【笠委員】  吉村先生がおっしゃったような,スペシフィックにソフトウェアの普及をもっと加速するためにコミュニティの中の資産も使うのですけれども,もう一つのインセンティブという意味では,そういう環境整備に当たっては非常に難しいです。
【加藤主査】  繰り返しですが,コミュニティに所属するソフトウェアのユーザがそういうトライアルを比較的簡単に実現できるような,そういう環境を提供すべきだという書きぶりにしようと思います。
【常行委員】  オープンソース・ソフトウェアについても国プロ同様の支援をする可能性についてと書かれているので,それで尽きていると思いますけれども,コミュニティの中から育ってきたソフトの中から重要な新しいものが生まれてくる可能性がありますので,そこの支援もするべきと思います。
【加藤主査】  もともと国でやったもの以外の中にも,国プロ等のアプリに準じて,国策として維持管理拠点で普及させるアプリになりたいアプリもあれば,すべきアプリもあるということですね。それは重要な視点なので,書きぶりを考えます。
 最後の4.4節に移りたいと思います。
【伊藤委員】  先ほども言いましたけど,ここになぜプリ・ポスト処理が入っているのかが分からないです。プリ・ポスト処理を含めて利用環境全体がなければ,産業界のユーザは使わないので,プリ・ポスト処理は別にここじゃなくて,もう少し前に述べるべきではないかと思います。
 あと,第4章というのはここで終わりですけれども,最後に4で示した6つの提言とありますが,6つの提言がどこを指しているのかがよく分かりません。
【遠藤参事官補佐】  済みません。事務局ですが,その部分は修正漏れです。
【伊藤委員】  分かりました。
【加藤主査】  時間がないので,先に問題点だけリストアップしましょう。
【吉村委員】  基礎基盤的な研究開発とか,次世代の実証研究云々というのは,例えば構造解析において,普通のメッシュを使っているのを,完全なオイラー・グリッドで解くとか,そのような理解でよいですか。
【加藤主査】  そうですね。
【吉村委員】  そうすると,エクサを開発するのであれば,メインテーマとして入ってきているという感じがしますけれども,そのあたりいかがですか。
【加藤主査】  それに関しては,エクサの開発のためにソフトウェア開発をどうするかというのは非常に重要なテーマなので,メインテーマですが,ただ,もうちょっと近場,例えば今「京」でチューニングしているものをどうやってもっと加速するかとか,あるいはエクサの実証研究というのは既にソフトウェアの形でないとなかなかできないと思うので,それをどうするかという話です。それをまずは書いたので,立場の違い,あるいはターゲットとして年代の違いで,この書きぶりが今みたいな書きぶりになっています。ただ,私も,少し弱いなと思っているのは,もうちょっと今の市販アプリ,あるいは今実証化されているアプリではできなくて,将来的に本当に効果があることを,しかもシーズだけじゃなくて,ニーズも踏まえて,研究開発すべきだという記述を少し入れた方がいいかなと思っています。
 ほかに何か問題点はありますか。なければ,先ほどのプリ・ポスト処理の話ですね。ここにプリ・ポスト処理の話が入っていることが悪いわけではないですね。
【伊藤委員】  必要です。
【加藤主査】  産業利用と言ったときに,非常に大規模なプリ・ポスト処理をどうするかということは非常に大事なので書いたのですが,プリ・ポスト処理に関して,例えば施策的なことを入れるということでしょうか。
【伊藤委員】  国プロアプリ等の普及促進の中に同様にプリ・ポスト処理というのも要るのではないかと思います。中長期というと,4.3とか4.2の次の時代という感じがしてしまいます。4.3が,4.1や4.2にも関わるというのであれば,それでも結構だと思います。
【加藤主査】  それは飽くまで国プロアプリですか。
【伊藤委員】  市販アプリは考えてないです。
【加藤主査】  それは既に施策としては動いていて,基本的には戦略分野の縦割り的な枠組みに対して共通基盤的なことを今計算科学研究機構でやることになっているのですが,それをもうちょっと明確に前面に出した方がいいということでしょうか。
【伊藤委員】  これだけだとどうしても解析エンジンのところだけしか余り考えてないように見える。
【加藤主査】  それは第4章に書くということですか。
【伊藤委員】  第4章に書くということです。産業界のユーザは,解析環境が欲しいのですから,プリ・ポスト処理まで含めて例えば国プロアプリのところにも必要だし,中長期的な高度化にも必要なのではないかということです。
【加藤主査】  分かりました。第4章の適切なところに入れたいと思います。
【吉村委員】  今の話にただ追加するだけですけれども,産業利用といったときにプリ・ポスト処理というのはセットで考えなければいけないので,最初からそれが入っているからということを書いてあるだけで済むのかなという感じがします。
【加藤主査】  それは3.1の最後に入っていますが,これは課題として入っている。だから,今の御意見はこれを施策的に書き込むかどうかですね。
【伊藤委員】  そういうことです。
【渡邊委員】  「おわりに」に書けばいかがですか。
【加藤主査】  国プロアプリの普及のところに書き込むようにします。

(2)その他

 加藤主査より,報告書について説明。

 加藤主査より閉会発言

お問合せ先

研究振興局参事官(情報担当)付計算科学技術推進室

電話番号:03-6734-4275
メールアドレス:hpci-con@mext.go.jp

(研究振興局参事官(情報担当)付計算科学技術推進室)