Javaゲーム作成総合スレ

**名前は開発中のものです。** · 2008/10/28(火) 18:23:40

Javaでゲームを作ろうと思っている人、今作っている人等が情報交換するためのスレです。
2Dのスレはありましたが、総合スレがなかったので立てました。
2D,3DどっちでもOKで、グラフィックス、アルゴリズム、お勧めサイト等、内容も自由です。

**名前は開発中のものです。** · 2009/01/06(火) 15:28:53

何もわからなければ普通にJOGLとかJava３D使ったほうがいいと思う

**名前は開発中のものです。** · 2009/01/06(火) 15:35:49

ええっ！そんな・・・
Javaだと数学公式で書いてあっても結構実装しやすいんですね。

**名前は開発中のものです。** · 2009/01/06(火) 16:40:07

2Dゲームの話もしませう

**名前は開発中のものです。** · 2009/01/07(水) 01:01:16

>>152
アルファブレンディング使わないのなら
Java2Dだけで十分使えるようになった。
u10以降。

標準APIだけでここまでよくなったのはすばらしいが、
せめて加算合成だけでも実装して欲しかったなぁ。

**名前は開発中のものです。** · 2009/01/07(水) 01:54:21

自分でブレンド処理クラスとか加算合成クラスとか作るとそんなに遅いんですか？
ピクセル単位でやるわけでu10でそのような処理用クラス用意したとしても結局同じだと思うんですけど。

**名前は開発中のものです。** · 2009/01/07(水) 02:33:37

ハードウェアアクセラレーションがきかねぇって話をしてるんじゃないか？

**名前は開発中のものです。** · 2009/01/07(水) 15:09:28

>147
146の者です。
鋭いですね。
元がゲーム屋さんではなくて、画像処理屋さんなもんで。
３Ｄ関連にうといので実験的に作ったのですが、
本格的な話になるとＰＣ上ではJavaよりはC#、C#よりはC++
という話になるんでしょうね。

**名前は開発中のものです。** · 2009/01/07(水) 16:18:55

いやJOGLで十分できるから

**名前は開発中のものです。** · 2009/01/07(水) 23:45:14

2Dとか3D以前に基本的なゲームループの話とか場面管理とかクラス構成の話もしてください

**名前は開発中のものです。** · 2009/01/07(水) 23:52:14

>>156
いや、君のHPの説明は結構参考になったよ。素直なコードだし、数学・物理の公式をコード化するのとか得意なんじゃないか？
ただHPにあったけどjvm上自動で行う、配列のindexチェックで遅くなるという主張はただの妄想でしかない。たしかに２０マイクロ秒ぐらいは違うだろうけどｗ

画像処理（CGとか非リアルタイムも）が得意なら、まずJavaで実験用コード・レファレンス実装して、これをハードに組み込みするという流れになるかもしれない。
その処理コードをハードに組み込みとか会社規模でやるんじゃないなら、PC（個人向け）ではもうすぐ環境が整うだろうけど、gpuやdirectx, openglのハード（ベクトルユニット）でやるようになると思う。
ベクタライズに多少書き直すことになるけど、PGする側からみれば結局は昔からあるコンパイラ最適化技術「ループ展開」の発展版でしかない。

http://pc.watch.impress.co.jp/docs/2008/1225/loilo.htm
GPGPU対応動画編集ソフト「Super LoiLoScope」がパッケージ販売

こんなのも出始めたから一般PG向けにそれら計算ユニット（ハード）が使える環境が整うまではあと２年ぐらい必要なんじゃないか？
といっても画像処理は分岐だらけだろうから、従来のようにピクセル毎でチマチマでもあまり差はないけど。
ただ、ベクトルユニットが使えるようになるとプログラミングスタイルやアルゴリズムが少し変わると思う。
リアルタイム処理（つまりあまり厳密じゃなくかなり適当でいい処理なもの）なら今なら普通にOpenGLが旬だし、２年ぐらいならJava3Dも来るかもしれない。

**名前は開発中のものです。** · 2009/01/08(木) 00:01:36

一言で言えばJOGLでおｋ

**名前は開発中のものです。** · 2009/01/08(木) 00:24:34

それと、sseも試行錯誤の末Javaからつかえるようになったけど、1.2-1.5倍、場合によっては1.7倍ぐらいかな。
よくエンコードソフトとSSE対応批評でこれだけ違うってのと大体同じ。

new float[1024]ぐらいまでなら普通にforでdst[k]+=src[k]とたいした差はなかった（高々1.1の向上程度）。
アセンブラも含めてかなり文書（英語）を読まないと使えるようにならないけど、苦労した割にはそれほど恩恵はないかな。

[16*16]程度の小さいブロックでforで処理すれば済むし、実際にはピクセル画像処理（アルファを使ったブレンドも含めて）は

native vectorization_mul (dst=new float[300*300], src=new float[300*300]);
とか、[300*300]など大きな塊（画像）を一度にマスク処理するようなことはしないからなぁ。

それと、intel ネイティブなのも痛いかな。opengl やgpu だとintel以外でも使えて汎用性高いし
専用ユニットだから[300*300]とかならsimdはそっちのシフトしていくような気がする（ゲームとかストリーミングとかのリアルタイム性なもの）。
一応[300*300]とかだと1.6倍ぐらいSSEの方が早いんだけど、intel用にチューニングするには結構苦労する。

この用途でのsseはgpuが普及するまでのつなぎ（５年ぐらいかな）かもしれない。
浮動小数FPUと同じくコンパイラ・言語がサポートしちゃえば楽なんだけど今のSSEの普及率はFPU程普及してないし言語・ライブラリのサポートはまだまだなのかもしれない。
これからのプログラムは画像・映像加工処理が多くでかいデータ量を一度に扱う必要があるから、５年後のsseはfpuと同じく気がつかないで使ってるとかになるんじゃないかと思う。

sseをjavaで使えるようにするにはム版のjniスレに試行錯誤を少し書いといた。
sseはintel ネイティブ機能なんだけど、だれかブログとかでまとめといて。

**名前は開発中のものです。** · 2009/01/08(木) 00:29:33

>>156
C++ってことなないよ。ライブラリはCで作るかもしれないけど、それを使うのはC++やJavaでも言語はあまり関係ない。複雑なのじゃなきゃruby（でOpenGLのAPIラップしたクラスを作って）でもいいんじゃない？
つまり今ならJavaでやるならJOGLで十分。
実際SWTみたくOpenGLやDirectXのAPIをJNIでラップしてあるだけだし。C++とJavaの差では、８００マイクロ秒ぐらいの差はあるかもしれないけど。

**名前は開発中のものです。** · 2009/01/08(木) 00:58:26

だからなんでJOGLでおｋな話をそう長々といちいちレスするんだ。一人で喋ってて楽しいのか？

**名前は開発中のものです。** · 2009/01/08(木) 02:07:06

ソフトレンダならもちろんマルチコア対応してるよね？

**名前は開発中のものです。** · 2009/01/08(木) 03:13:55

>>163
てか、おまえ誰だよ。何も作れないくせにJOGLの宣伝部長かｗｗ

**名前は開発中のものです。** · 2009/01/08(木) 04:00:12

無能が能書きたれるのはどこも一緒だなｗ

**名前は開発中のものです。** · 2009/01/08(木) 04:06:29

>>163
じゃJOGLでおｋなことを長々と語ってくれないか？
おまえみたいな無能じゃ無理かｗ
JOGLていうよりもOpenGLすら使ったことないんだろうｗｗ

**名前は開発中のものです。** · 2009/01/08(木) 07:19:56

>>154
自前のCompositeを使うと、内部でGeneralCompositePipeという物が使われる。
sun.java2d.pipe.GeneralCompositePipeの88-89行目を見ると、
　dstIn = dstRaster.createChild(x, y, w, h, 0, 0, null);
　dstOut = dstIn.createCompatibleWritableRaster();
となっている。この時確保されるdstOutのサイズはw×hではなくて、dstRasterと同じサイズになる。
(java.awt.image.Rasterのソースを参照)
多分開発者は、createCompatibleWritableRaster(w,h);と同じ結果を期待していたんだと思う。
そのせいで、大量のメモリの確保を何度も行う事になる。何度も。
しかも、大きい図形は内部で32×32に分割して描画しているからメモリを確保する回数がさらに増加する。
これではアクセラレーション以前の問題。
どう見てもバグだけど、誰もゲームに使わないからか特に問題にならず、一向に修正されない。
描画に使う一時的なRasterは一々確保せずにキャッシュを使ってほしいけど、面倒だったのか毎回確保してる。
だから、自作Compositeをゲームに使いたいなら、Graphics2Dを使わず自分で処理するのが無難。
英語が得意なら、バグを報告して修正を待つ手もあるけど。

あと、Composite内で使うgetPixels()やsetPixels()も妙に遅い気がする。
sun.awt.image.DataBufferNativeが怪しい。自分の所だけかもしれないけど。

**名前は開発中のものです。** · 2009/01/08(木) 12:20:24

>>168
だからその程度の技術力しかないなら、普通にJava API（高度に抽象化したAPI）を使えばいいよ。
確かjdk1.5ではBufferedImageは全てキャッシュされるって書いてあったから、その指摘も数年で色あせるんじゃないか？ｗ
そもそもjava.awtパッケージなのに、内部実装sun.*パッケージのソースにいちゃもんつけてるし、結局おまえじゃ何も出来ないだろｗｗ
そんなにこだわりあるならネイティブ向けパッケージ使え。タコがｗ

>>163
それと、JOGL(OpenGL)はAPIであって、GPUとかSSEはハードであって、上ではハードの話が書いてあるんだけどこの区別ついてる？
君の作ったOpenGLを使ったゲームを出してみ。

**名前は開発中のものです。** · 2009/01/08(木) 12:40:43

何度読んでもツッコミどころ多いな。
一般人程度の知識しかなく大してハード（メモリやCPU）のこと知らないのによくここまで妄想して大口たたけるものだと感心するよ。
そこまでJava/JVM（高度に抽象化したプラットフォーム）にこだわりがあるなら、まずは各ユニットの仕様知り各ハードの役割とか勉強したらどうだ？
バスとかいっても何のことか分からないでしょ。ハードのことをとことん知ると、java.awtも含めて君の指摘する文句たらたらのアプローチになるから。
内部に思い入れなくアルゴリズムの研究するだけなら、Javaらしく、良い子はBufferｒeImage.getRGBを使え。ｗ

**名前は開発中のものです。** · 2009/01/08(木) 19:22:31

>>169
(´･ω･｀)？

**名前は開発中のものです。** · 2009/01/08(木) 19:59:44

もうさぁ、そういうのどうでもいいからさぁ。
ゲームを見せてよ。
みんなそんなに語ってるんだから、凄いゲームいっぱい作ってるんでしょ？
どーなのよ？
それとも、ゲームは作れないけど知識は凄いよ！
みたいなことアピールしてるだけ？

**名前は開発中のものです。** · 2009/01/08(木) 21:24:31

最近Javaアプレットで作られたすげーゲームって何かないですか？
刺激にしたいです

**名前は開発中のものです。** · 2009/01/08(木) 21:43:50

突然喧嘩口調のレスが来たから何事かと思って変なレスしてしまった。ただの人違いか。
特に>>170が誰宛なのか判らずに悩んだ。>>168はjoglの人とは別人なんだけど。
＞だからその程度の技術力しかないなら、普通にJava API（高度に抽象化したAPI）を
そのJava APIの話が>>168。java.awt.*とjava.awt.image.*を参照。
あと、「だからその程度の技術力」の根拠詳しく。joglの人と間違えたんだと思うけど。
＞確かjdk1.5ではBufferedImageは全てキャッシュされるって書いてあったから、その指摘も数年で色あせ
createCompatibleWritableRasterは0で初期化したラスターを返す。(これは仕様)
つまり、憶測通りBufferedImageがキャッシュされるとしても、
全画面を黒く塗り潰す処理を何度も実行したのと同じ負荷がかかる。
これを防ぐには、無駄な領域を確保せず、staticなソフト参照を使って使い回す必要がある。
それにはGeneralCompositePipeの修正が必須。数年で色あせてくれるんなら助かるんだけど。
＞そもそもjava.awtパッケージなのに、内部実装sun.*パッケージのソースにいちゃもんつけてるし、結局おまえじゃ何も出来
java.awt.image.Rasterの方は修正すると既存のプログラムに影響しうる。変更は望めない。
sun.java2d.pipe.GeneralCompositePipeの内部処理を変更するべき。
あと、デバッグツールによりsun.awt.image.WritableRasterNative.setPixels()が遅い事が分かっている。
DataBufferNativeが関係している可能性がある。これは自分の環境が悪い可能性が高いけど。
何もできないのは同意。これを修正できるのはVMの開発者だけ。バグ報告も自力じゃ無理。

あと、BufferdImage.getRGBのソースを見たけど、内部で同じメソッドを呼んでいるから速度は大して変わらない。

>>172
ゲームのエフェクト等に有効な加算合成がJava2Dに搭載されていないから、
自前でCompositeを用意して解決しようとしたら異常な遅さで困った。
一番重い筈のcompose()の中身を全部コメントアウトしても尚遅いまま。
なかなか原因が分からず、苦労している内にGeneralCompositePipeのバグに到達した。
AlphaComposite以外を使うと異常に遅くなるのは主にこの手抜き実装のせい。
この事を話す機会が無かったからつい。ゲームは作れないけど知識は凄いよ。

**名前は開発中のものです。** · 2009/01/09(金) 00:21:25

AlphaCompositeはハードウェアアクセラレーションあるから自前のは勝負にならない
標準APIで加算合成実装してもらう以外に方法がないのでJOGL使うのが一番無難

**名前は開発中のものです。** · 2009/01/09(金) 00:23:05

どうでもいいから黙ってろ。

**名前は開発中のものです。** · 2009/01/09(金) 00:27:02

>>176
お前が荒らしか

**名前は開発中のものです。** · 2009/01/09(金) 02:08:32

だから、その程度の知識しかないなら内部にさわるのは止めとけ。
おまえはよく人のソースを読んだりしてるようだからどちらかといえば公式どおりの素直なコードを書くほうが向いていてるんじゃないか？
内部の職人技コードにはついて来れないだろう。さっそく

＞これを修正できるのはVMの開発者だけ

とかついて来れないじゃん。バグ報告はパラダイスでフォームどおりに書くだけだろ（英語）。
俺の場合はたしかキャプチャーのバグ話で送ったけど担当者から丁寧な返事がきたぞ。
つまりおまえ技術力、知識、教養は、ウンチクだらけで実際はたいしたことないってこと。
中途半端な知識しかないのに「ウンチク電波」を垂れ流すのやめてくれないか？

**名前は開発中のものです。** · 2009/01/09(金) 02:29:19

それと、javaで、それもGraphics2Dで作る限り速くなるはずはないな。
たとえおまえが言うウンチクの場所(getRGBやclass Raster)が改善されたとしても、ゲームとして１０倍５０倍速くはならないだろ？
Java2Dでも複雑なテクスチャや画像を貼り付けたり、頻繁にpaintをしないなら、今のCPUの力技ではゲーム上全く問題ない。
まさかJava2Dだけで、PS3並みのゲームを作ろうと意気込んでないか？ｗそれ、おまえの妄想だからｗ

ゲームでも何でも３Dの場合は、画像処理とは考え方が違うし加算合成が速い・遅いとか（ソフト上アルゴリズム上の問題は）関係ないから。
Compositeが遅いとかも、１画像（１フレーム）の処理に３秒以上かかるとかじゃないだろ？
アニメーションにすると遅いって言うなら、それはおまえが画像処理（静的処理）とゲーム（リアルタイム性）の区別がついてないで、
同じ手法（考え方）でやってるのが問題。おまえは、知識が凄いんじゃなくて、おまえは頭が固く、ウンチクの塊だって気がつけ。
どうせ、おまえが書くコードなんかifばっかりなんだろ。ｗ

>>170はIDのとおり>>168だろ。IDでつながってるのから分かるだろｗおまえが無能だってことが書いてある（笑）

**名前は開発中のものです。** · 2009/01/09(金) 02:46:49

gpgpu専用画像ソフトのリンクあるけど、販促デモ（動画）みてないの？
たぶん、今までの画像とかゲーム・アニメーション（リアルタイム）の処理することに対する考え方が全く変わるから。
それに、既存のC++とかC#(DirectX)と同じ土俵（従来のコンソール型のゲーム）だとJavaは全く不利になるけど、
それ見ると、Javaでゲームを創るていう方向性（どういうゲームを作りたいのか）も変わるんじゃないか。

純粋なゲームは従来どおりOpenGL/DirectXとかのゲーム向けAPIでいいわけで、Javaで言うゲームの場合はそういった純粋なゲームとGUIとの垣根がなるなるんじゃないかな（これもグーグルマップみたいなWeb 2.0なのかｗｗ）。

**名前は開発中のものです。** · 2009/01/09(金) 05:08:37

>>175　アクセラレーション以前に重大な問題(バグ)がある。それを解決すれば一応使えるレベルにはなる。

>>178-180
言ってる事はまともなのに何故か微妙に喧嘩腰。2chでは非常に珍しいタイプ。
職人技コードとバグ報告とウンチク電波の関係は謎だけど、とりあえず報告しておいた。サンクス。
あと、RasterやgetRGBはともかく、GeneralCompositePipeのバグは数十倍の差が出る。というか出た。
それから、別にPS3みたいなゲームを作りたいんじゃなくて、
折角Compositeの様な仕組みがあるんだから有効活用したいと思ってただけ。>>174の後半参照。
流石に1フレームに3秒はかからないけど、0.3秒はかかる。つまり約3fps。これじゃゲームは無理。
composeの中身を全部コメントアウトしても尚3fps。でもAlphaCompositeを使うと60fps。
バグの影響が出ないようにウィンドウサイズを描画範囲と同じサイズにしたら自作Composeでも60fps。
この時点で、アルゴリズムの問題じゃない事が分かる。処理を省略しても遅いから。

>>170は確かに自分宛だけど、わざわざ分割する意味が分からなくて悩んだ。
とりあえず、何でさっきから散々に言われてるのかは理解した。
自分は「遅い」を「とても我慢できない遅さ(3fps)」という意味で使ったけど、
相手は「遅い」を「なんかもたつく程度(25fps位？)」と解釈してた。
それで、「お前のアルゴリズムが悪い。それを一々VMのせいにするな」と。
具体的な遅さを説明しなかった自分が悪いんだけど。

**名前は開発中のものです。** · 2009/01/09(金) 08:25:45

>>181
ここはゲームに関係したもんじゃないと、君のウンチク自慢でしかないってこと
リアルタイムなわけで、１ピクセルごとにチマチマやるような手法じゃ通用しないってこと知らないだろ。
チマチマを否定するつもりはないけどゲームではあまり関係ないし、そのうちアルファブレンド関係全て（フィルター処理）はGPUの手法になるよ。

アルゴの実験ならJava2D、Java3Dを画像処理に応用したいならストリープ・プログラミングでも調べてみたら？
今までのプログラミングの概念が全く変わってしまい、君のような石頭オジサンがスカスカのスポンジに変わっちゃうからｗ
といっても、ゲームとかアニメーションとか君は作れないから無理かぁ（笑）

**名前は開発中のものです。** · 2009/01/09(金) 11:22:16

>>182
だから、この遅さは「1ピクセル毎にチマチマ」以外に大きな原因があるんだって。60fps→3fpsが異常なのは分かるだろ。
報告テンプレのためにあれこれ検証した結果、VolatileImageの部分をBufferedImageにすれば、とりあえず解決する事が分かった。
BufferedImageのサイズを大きく変更すると、描画範囲が変わらないのに少し重くなるから、一応バグはあるようだけど。
GPUの事は知っているけど、Javaの標準機能でやりたくて。
贅沢を言わなければ1px毎にチマチマやっても平気。不具合に遭遇したら話は別だけど。
問題は解決したし、さっきから長文の応酬でスレが流れているからこの辺で。

ところで相手をオジサン呼ばわりって事は学生？
自信満々の態度から経験豊富な本職のプログラマーだと思ったんだけど。口調が違うから別人？

**名前は開発中のものです。** · 2009/01/09(金) 12:48:54

バク見つけたらさっさとバグパラダイス（英語）で報告しとけ。
それぐらいもできない奴が不満たらたらウンチクたらたら書くな。いしあたまｗ

**名前は開発中のものです。** · 2009/01/09(金) 13:29:36

>>179
2Dゲーだけならu10で実用的になったのにゲームで多用する加算合成がないというオチが非常につらい
あと速度は真っ先に考えるところだと思う
VGAサイズで60fpsとかは普通はやりたいと考えるだろう
Java2Dのハードウェアアクセラレーションの範囲が大幅に増えたのにソフト演算が入った瞬間に速度大幅低下はつらい

>>183
そのバグはu7以下とu10以上でも同様の結果？フレームレートだけだとあいまいすぎるから
μ秒単位でだしてみたら？

**名前は開発中のものです。** · 2009/01/09(金) 15:30:52

へんなのに居座られたもんだな。

**名前は開発中のものです。** · 2009/01/09(金) 15:49:56

>>185
画像処理してるわけじゃないだろ。そんな凄いゲーム作るんならJava2Dにもうこだわるのやめたら？
どうせVGAサイズで60fpsなんて作れないくせにｗｗｗいしあたま君ｗｗ

**名前は開発中のものです。** · 2009/01/09(金) 15:55:43

もう一度いっておくけど、ゲーム作りと、作るための言語（ライブラリ）は全く関係ない。
GPUだと、1600*1200で60fpsとか余裕だけど、ハードのこと全く知らないでしょ？
なーんにも作ったことない石頭君は、そのあたりのことを石頭にしっかり叩き込んでおくように！

**名前は開発中のものです。** · 2009/01/09(金) 17:46:15

>>187,188
ソフトレンダが入らないのなら60fpsは余裕
だから標準API以外で実装されてないと困るという話なのにどういう解釈してるんだ？

別に60fpsがすごいゲームの基準じゃなくて最低限余裕でクリアすべき部分だから的外れだよ

**名前は開発中のものです。** · 2009/01/09(金) 18:50:38

>>189
まずは君が造ったゲームを見せてみろ

**名前は開発中のものです。** · 2009/01/09(金) 20:10:47

>>189
ゲームだと論点以外の場所に突っ込み入りまくりなのが目に見えてるんで、
何か単純なサンプルとかないですか？
自分でも何か作ってみようとは思ってますけど。

**名前は開発中のものです。** · 2009/01/09(金) 20:28:01

久しぶりにJavaゲーム製作スレに来たら盛り上がっていて嬉しいでちゅ
と書き込もうと思ったら、ものすごい荒れてて怖いでちゅ＞＜

みんな、仲良くするデちゅ＞＜

**名前は開発中のものです。** · 2009/01/09(金) 21:48:12

サンプル作ろうとしたけど思った以上に面倒だな、いきなり挫けそう orz

**名前は開発中のものです。** · 2009/01/09(金) 23:26:09

独自のCompositeの検証だから適当にスプライトを大量に描画すればいいだけかと

**名前は開発中のものです。** · 2009/01/12(月) 18:38:55

>>185
fpsが極端に落ちるのは、多分VMじゃなくて自分のGPUの問題。
(VolatileImageを使用していた所をBufferdImageに変更したら大幅に回復した)
この事に気付かないで、他に原因があると思い込んで調査していていたから、色々勘違いしてしまった。
あと、GeneralCompositePipeのあの部分は別にバグではなくて、Rasterの方が間違っているだけみたい。
(実際に使われているsun.awt.image.IntegerInterleavedRasterクラスでは修正されていたので無関係)

BufferedImageのサイズを大きく変更した時の処理速度低下についてだけど、Compositeに関係なく発生する。
けれど、特に異常なメモリ確保増大とかは無かったし、実害は無さそう。

結局、バグを修正しても遅いまま。これ以上は無理だろうし諦める。

**名前は開発中のものです。** · 2009/01/14(水) 19:05:48

だからハードウェアアクセラレーションが使えないのを選択した時点で速度に文句を言うのはやめよう

**名前は開発中のものです。** · 2009/01/14(水) 19:06:42

あとVolatileImageのほうが遅いのは当たり前だろうと

**名前は開発中のものです。** · 2009/01/17(土) 01:10:49

>>194
でも、加算半透明のための独自のCompositeって、自分のような日曜プログラマにはけっこう面倒。

自分もJava2Dでゲーム作ってるけど、加算半透明はもう諦めたよ。

**名前は開発中のものです。** · 2009/01/18(日) 22:40:17

色々なサイトのjarファイルを解凍して中身のファイルを見てたんですけど
ファイルの中に「.au」形式のファイルがあって、データベース的な使い方をしているみたいなんですけど
このau形式のファイルはどうすれば中身が見れますか？

**名前は開発中のものです。** · 2009/01/18(日) 23:30:29

>>199
それ音声ファイル
ttp://ja.wikipedia.org/wiki/Sun%E3%82%AA%E3%83%BC%E3%83%87%E3%82%A3%E3%82%AA%E3%83%95%E3%82%A1%E3%82%A4%E3%83%AB