Wikibooks jawikibooks https://ja.wikibooks.org/wiki/%E3%83%A1%E3%82%A4%E3%83%B3%E3%83%9A%E3%83%BC%E3%82%B8 MediaWiki 1.39.0-wmf.22 first-letter メディア 特別 トーク 利用者 利用者・トーク Wikibooks Wikibooks・トーク ファイル ファイル・トーク MediaWiki MediaWiki・トーク テンプレート テンプレート・トーク ヘルプ ヘルプ・トーク カテゴリ カテゴリ・トーク Transwiki Transwiki‐ノート TimedText TimedText talk モジュール モジュール・トーク Gadget Gadget talk Gadget definition Gadget definition talk 0 3384 205922 205669 2022-07-28T04:49:40Z Ef3 694 mozilla-japan は mozilla から分裂し、2022年7月28日現在 http://www.mozilla-japan.org へはアクセスできない。 wikitext text/x-wiki <small> [[情報技術]] > 高等学校情報C</small> ---- ==情報C== 情報Cでは、情報のデジタル化のしくみについてより詳しく説明する。また、通信機器のしくみについて詳しく説明し、その使い方について述べる。 ===情報のディジタル化=== [[高等学校情報B]]では、様々な情報を0と1だけを用いて表現する方法について述べた。ここではそれらの手法についてより詳しく説明する。 ====情報のディジタル化の仕組み==== ここでは、数値、文字、音、映像データなどの扱い方についてより詳しく述べる。 =====数値===== まず、数値について説明する。[[高等学校情報B]]では、数値は実数と整数の表わし方について 述べた。ここではそれらについてより詳しく扱う。整数は、10進数で書かれた数を2進数で表わすことで、 デジタルデータとすることが出来た。ここでは、10進数で書かれた数と、2進数で書かれた数の関係について 扱う。10進数で、'abc.de'と書かれる数があるとする。例えば、123.45などの小数は、この形で表わされる。 このとき、この数は :<math> 10^ 2 a + 10^ 1 b + 10^0 c + 10^{-1} d + 10^ {-2} e </math> と書くことが出来る。これは、10進法では、大きさが10倍になるごとに、桁が1つずれることに対応している。 このような記法は、1つの整数の組(a, b, c| d, e)から、唯一の10進数の数を定める方法を与える。ただし、|の記号は、小数点の位置を表わしている。 このことの逆として、全ての10進数で書かれた有限小数に対して、ただ1つの数の組が対応することも わかる。ただし、数の組に含まれる整数の数は、与えられた有限小数の性質に応じて変化するものとする。 逆の証明は数学的帰納法によらなければならないのでここでは省略するが、ある整数nに対して、対応する数の組を見つけ出す方法を与えておく。 # nよりも小さく、しかも10のべき乗で表わされる数の中で、最も大きいものを見つける。 # 1で得たべき乗の指数をeとする。 # nを<math> 10^e</math> で割って、商dと余りrを求める。 # 整数の組の中で、最も上に書くべき量が、dである。 # 1から4の作業をrに対して行なう。rが0だったときには、ここまでの手順で整数の組が見つけ出されたことになる。 この展開は、10のべき乗ではなく2のべき乗を用いて行なっても、全く変化することなく行なうことが出来る。 同様に得られた数の組に対して、ただ1つの小数を対応させる方法もすぐにわかる。例えば、数の組(a, b, c, d, e|)に対しては、 :<math> 2^4 a + 2^3 b + 2^2 c + 2^1 d + 2^0 e </math> というただ1つの整数が対応する。このような記法で書かれた数を10進数に対して2進数と呼ぶ。実際には10や2だけでなく、 任意の自然数nに対してn進数を構成することが出来る。 ;問題例 :;問題 ::次の10進数を2進数を用いて書き直せ。 :::(I) 5 (II) 20 (III) 0.5 (IV) 320.75 :;解答 ::先ほど得た手順を用いて、与えられた数を展開していけばよい。小数の扱い方も展開を用いればよいが、若干非直観的に見えることがあるので注意が必要である。例えば、10進数の0.1は、2進数では無限小数になる。 :;(I) ::<math> 5 = 1 \times 2^2 + 0 \times 2^1 + 1 \times 2^0 \rightarrow 101 </math> :;(II) ::<math> 20 = 1 \times 2^4 + 1 \times 2^2 \rightarrow 10100 </math> :;(III) ::<math> 0.5 = 2^{-1} \rightarrow 0.1 </math> :;(IV) ::<math> 320.75 = 2^8 + 2^6 + 2^{-1} + 2^{-2} \rightarrow 101000000.11 </math> :;問題 ::与えられた2進数を、10進数に変換せよ。 :::(I) 111 (II) 11011 (III) 0.1 (IV) 1101.001 :;解答 ::上で用いた展開の逆を行なえばよい。小数についてはやはり注意が必要である。 :;(I) ::<math> 111 \rightarrow 2^2 + 2^1 + 2^0 = 7 </math> :;(II) ::<math> 11011\rightarrow 2^4 + 2^3 + 2^1 + 2^0 = 27 </math> :;(III) ::<math> 0.1 \rightarrow 2^{-1} = 0.5 </math> :;(IV) ::<math> 1101.001 \rightarrow 2^3 + 2^2 + 2^0 + 2^{-3} = 13.125 </math> :以上の手順で数値を2進数で表わすことができることがわかった。 実際には2進数で大きい値を書くと扱いづらくなることから、8進数（[[w:オクタル]]）や16進数（[[w:ヘキサデシマル]]）が用いられることが多い。 8進数や16進数が用いられるのは、8や16が、2のべき乗で表わされる数であり、対応がつけやすいことによる。 例えば、111000111000のような大きい2進数があったとする。 このとき、8進数では、この値を3つずつに区切って、読み取ればよい。 これは、8が2の3乗に等しいことによる。 上の例では、111は、8進数で7に対応し、000が、0に対応することから、8進数では7070と書くことが出来る。 ここで、数が8進数で書かれていることを示すために昔のC言語の八進数リテラル表現を借りて "0" を前置して、07070 の様に表記することがある<ref>[[C言語|標準C言語]]では、07070のほか0o7070のように 0o を前置する方法でも8進数リテラルを表現でき、単にゼロを前置する表記は「単なる桁合わせのつもり」で書いてしまう事故が後をたたないため、現在は 0o を前置する方法が推奨されている。</ref>。 一般に、8進数では0から7までの数字を用いることに注意。 一方、16進数では、2進数を4つずつに区切って扱うことが出来る。 16進数は10進数より多くの数字を使うため、0から9の数字では数字が足りなくなる。これを補うため、9の後に A,B,C,D,E,F あるいは a,b,c,d,e,f が用いられる。 上の例は、 1110: E, 0011: 3, 1000: 8を用いて、E38と書ける。 16進数は、C言語の16進リテラル表現を借りて "0x" を前置して 0xE38 の様に表記することが多い<ref>他の16進数表記としては E38₁₆のように基数を右下に小書きする表現や、$ そ前置あるいは後置する表現がある。</ref>。 次に、負の整数の扱い方について述べる。 ある数の正負を表す方法は、いくつかある。 * 絶対値と1ビットの正負の別を表す情報「[[w:符合ビット]]」で表す方法。 * 負の数を[[w:2の補数]]を用いて表す方法。 が代表的だが、[[w:1の補数]]など他の方法が採用される場合もある。 多くのプロセッサーでは、整数には2の補数表現が用いられ、浮動小数点数には符合ビット表現（符号＋指数＋仮数）が用いられる。 =====文字===== [[高等学校情報B]]では、コンピュータが扱う文字に対して互いに重複しないある数値を当てはめ、それによって文字を扱うことを述べた。ここでは具体的な 文字コードとして[[w:アスキー]](ascii)コードと、[[w:ユニコード]](UNICODE)について扱う。asciiコードは、aからzまでの小文字アルファベットとAからZまでの大文字 アルファベットを含む、128種類の文字を表わす広く用いられる1[[w:バイト]]の文字コードである。それぞれの文字と数値の対応は[[w:アスキー]]を参照。 実際に文字が数値と対応付けられていることを見るために、ここでは[[w:プログラミング言語]][[w:Python]]を用いる。Pythonについて詳しくは、 [[高等学校情報B]]を参照。Pythonはデータ型として文字列を 扱うことが出来るが、特に、"\xi??"の記法によって、1バイトの情報を直接書きこみ、それを文字列として扱うことが出来る。ここで、??は、16進数で 表わされる数値である。そのため、ここでasciiコードに対応する数値を書きこみ、結果が文字として表示されれば、asciiコードが対応する文字を 表わす数値を与えていることが示される。具体的には、 print "\x61" などを実行してみるとよい。16進数での61は、asciiコードでは'a'に対応する。そのため、これを実行すると、画面に'a'が出力されるはずである。 次に、ユニコードについて述べる。世界には様々な文字が存在するが、それらの文字には互いに重複した文字コードが与えられており、異なった言語の 文字を同じファイル内で用いるためには特別な工夫が必要であるという情況があった。その情況を打開するために用いられるようになった文字コードが ユニコードと呼ばれる方式である。ユニコードは世界で用いられる全ての言語に対して、単一の文字コードを与えて、それらを統一的に扱うことを 目指した文字コード体系である。 ユニコードを作成することは、用いる情報を増やすことで、 扱う文字の数を無限に増やせることを考えると、単に現存する文字を集めることだけが目的のプロジェクトのように思われる。しかし、実際には asciiコードなどの有力な文字コードに対する互換性などを保持するため、それらと重複しない文字コードを作成することが重要となった。 asciiコードでは、当てはめられている文字は128個だけである。一方、1バイトの情報は、256通りの情報を表わせる。これは、1バイトが8[[w:ビット]]に 対応しており、用いられる情報が <math>2^8 = 256</math> 通りだけあることによる。そのため、asciiコードに対応する文字に1バイトだけを当てはめるコードを用いても asciiコードで用いられていない数値に対応するバイトから始まるバイト列を他の文字に対応させることで、2、3、4バイトの情報で表わされる文字を 作ることが行なわれた。現在よく用いられているユニコードとして、[[w:UTF-8]]と呼ばれる文字コードがあるが、これはasciiとの互換性を維持している。 この文字コードは、1から4バイトの情報をそれぞれの文字に当てはめている。日本語で用いられるひらがな、かたかな、漢字はどれも3バイトで表わされる。 通常、日本語のデータを扱うためには、<math>256 ^2 = 65536</math> 通りの文字を用いれば事が足りるため、これまでの日本語文字コードでは、それぞれの文字を 2バイトで表わすことが多かった。一方、UTF-8を用いると、1文字当たりに必要となるサイズが増えるため、日本語のデータの大きさが増えることが 問題となる。しかし、UTF-8を用いることで他の言語との親和性が高くなることから、UTF-8は広く用いられるようになっている。 UTF-8の使い方を確かめるために、Pythonを用いてみる。例えば、日本語の'あ'に対応するUTF-8は、'0xe38182'である。ここで、 print "\xe3\x81\x82" を実行すると、'あ'が表示されるはずである。ただし、これは用いている環境が、UTF-8の日本語を表示できるかによるため、情況によっては うまくいかないこともあるかも知れない。 <!-- Fedora Core 3 では、ほぼ初期状態でうまくいった。 --> =====音===== 次に、音の保存方法についてより詳しく述べる。[[高等学校情報B]]では、音がただ1つの数値を時間的に 記録し続けることで、デジタルデータへと変換できることを述べた。このような音声データを[[w:PCM]]形式と呼ぶ。この形式は 非常にファイルのサイズが大きくなることが多く、楽曲を配付するような目的ではデータの通信に時間がかかることが 問題となる。この問題を解決するため、データの[[w:圧縮]]を行なう方法が工夫された。圧縮とは、データの性質を できるだけ変えないように保ったまま、データのサイズを小さくすることである。データの圧縮については次章でより詳しく扱う。 <!-- データのサイズを'情報量'と呼ぶのは間違いだと書いてあったのはどこだっただろうか ... 。 情報量を減らさないようにサイズを減らすのが圧縮(可逆圧縮)である。 --> よく用いられる圧縮形式には、[[w:MP3]]形式がある。この圧縮法の詳細にはふみこまないが、詳しく知りたい場合にはja.wikipediaの対応する 記事などを用いるとよいだろう。また、上で用いた圧縮形式は、ライセンスに制約があり、保存されたファイルを用いることに 制限が生じる場合がある。この制限を乗り越えるため、[[w:Ogg Vorbis]]形式の圧縮法が提唱された。 この形式は、ライセンスによる制約が生じないように工夫されているため、今後広まっていくものと考えられる。 <!-- 希望的観測もあるが ... 。今の時点では、どのように変化が起こっているかはよくわからないので。 --> =====画像===== 次に、画像の保存法について詳しく述べる。[[高等学校情報B]]で、画像が各点([[w:ピクセル]]と呼ぶ)の 赤、青、緑の光の強さ(この3色を[[w:RGB]]と略すことがある)で、表わすことが出来ることを述べた。実際には、音楽と同じ理由で、 映像データも圧縮を行なって、データサイズを小さくすることが多い。よく用いられるファイル形式には、[[w:GIF]]、[[w:PNG]]、[[w:JPEG]]などがある。 <!-- JPEGは、本来ファイル形式ではなかったはずだが ... 。何だっただろうか ... 。 --> ここでは、画像を扱う簡単な方法として、[[w:XPM]]形式について述べる。XPM形式とは、文字列をそのまま画像として扱う方式であり、GUIのツールが なくても画像を扱うことが出来る方法として重宝される。XPMは[[w:C言語]]で用いることを考えて作られた形式であるので、その記録方式は 少し妙に見える所を含んでいる。ここでは簡単なXPMを扱う。 1: static char ** a = { 2: "5 5 2 1", 3: "w c #ffffff", 4: "b c #000000", 5: "bbbbb", 6: "bwwwb", 7: "bwbwb", 8: "bwwwb", 9: "bbbbb" 10: } 典型的なXPMのデータは上のようになっている。最初のstatic char ** a = { と、 最後の }の部分はC言語の対応する機能なのでここでは述べない。 2行目の"5 5 2 1"は、それぞれ画像の幅、高さ、用いる色の数、それぞれのピクセルを表わすのに用いる文字の数を定めるパラメータである。 ここでは、縦横5ピクセルの図形で、色の数は2色とし、それぞれの色を扱うためにbとwの文字を用いているのでこのような値にセットしてある。 3、4行目は、それぞれの文字にどの色を当てはめるかを定める行である。ここで、"w c #ffffff"の部分は、wに対しては、カラー(Color)で、#ffffff で表わされる色を当てはめることを述べている。ここで、ffffffの表式のうち、最初の2文字は、赤の強さに対応しており、その強さを 16進数で表わした色を表わしている。また、3,4文字目は緑の強さ、5,6文字目は青の強さをそれぞれ表わしている。全ての色の強さが最も 強いときには、対応する色は白であることが知られている。結局3行めは、wに白を当てはめることを述べている。4行目も似た文だが、ここでは、 bに黒を当てはめている。実際の画像データは5から9行目に記録されている。ここでは、白で黒を囲んでいるように見えることを意図しているが わかりづらいかも知れない。実際にXPM形式のデータを扱えるソフトウェアとしては、[[w:en:ImageMagick]]などが知られている。 <!-- PNG形式に直してアップロード --> ====情報機器の種類と特性==== ここでは、様々な情報機器について説明する。具体的には、[[w:プリンタ]]、[[w:スキャナ]]、[[w:デジタルカメラ]]などを扱う。 プリンタは、映像などのデータを紙に印刷するための情報機器である。プリンタはビデオカード同様、映像データを3色を用いて 表わし、その情報を元に、紙のある部分に印刷する色を決める。ここで、プリンタが紙に色を転写する方法がいくつかある。 代表的な例として、[[w:ドットインパクトプリンタ]]、[[w:インクジェットプリンタ]]、[[w:レーザプリンタ]]などがある。 ドットインパクトプリンタは、やや古い型の白黒プリンタに多く、[[w:インクリボン]]を機械的に叩きつけることで紙に色を写す方式 である。インクジェットプリンタは、近年でもよく用いられる方式であり、カラーと白黒の両方が扱えるタイプが多い。 これは、画像データに対応するように紙にインクを吹き付けることで、紙に色を写す方式である。レーザプリンタは、 やや高価であるが、高速な印刷が出来るため、オフィスなどの業務用のプリンタとして用いられることが多い。こちらも 白黒とカラーを使いわけられるタイプが多い。方式としては、それぞれの色に対応した[[w:トナー]]を用い、それに[[w:レーザ]]を 照射することで、色を写すという方法を用いている。ここで、レーザとは波長のそろった光のことであり、これは減衰することなく 長距離を伝搬することが知られている。また、通常の光と比べてより強い指向性があるため、細かい操作にも向いている。 レーザの照射原理はかなり複雑であることが知られている。[[w:レーザ]]、[[量子光学]]などを参照。 次に、スキャナ([[w:イメージスキャナ]])についてまとめる。スキャナとは、紙などを機械に挟みこみ、その紙に描かれている内容を、デジタルデータに 変換する装置である。描かれている内容を変換する点で、この機器はデジタルカメラに似ているが、大量のデータを読みこむ 用途などでよく用いられる。また、プリンタと同じ機具にスキャナの機能をつけた製品もあり、このような製品はオフィスなどでよく用いられている。 最後に[[w:デジタルカメラ]]についてまとめる。デジタルカメラは、既存のカメラと同様、光を集め、それを記録することが出来る 装置である。デジタルカメラと既存のカメラの違いは、既存のカメラが光を記録するのに[[w:化学反応]]を用いるのに対して、 デジタルカメラは、光をデジタルデータに変換する機具を用いることにある。ここで、既存のカメラで用いられる化学反応は、 カメラの種類によって異なっているが、銀塩を用いた反応が有名である。 これらの機具を用いて、写真をデジタルデータとして扱ったり、デジタルデータを紙に出力したりすることが出来る。 ただし、デジタルデータは複製が用意であるため、写真を何らかの方法でデジタルデータとして公開した場合には、 それらが不特定多数の人の目にふれる可能性が高い。このことは、写真に写った人の、[[w:肖像権]]を侵害する 恐れがあるため、写真を公開するときにはごく注意し、相手の確認を求めるなどの対策を取ることが望ましい。 ====情報機器を活用した表現方法==== ここまでで様々なデータをデジタルデータとして用いる方法について説明して来た。ここまでで知った情報機具などを用いて、 何らかのプレゼンテーションなどを行なうことがここでの課題である。 *課題 デジタルカメラ、スキャナなどの機具を用いてプレゼン資料を作成し、実際にプレゼンテーションを行なう。 ===情報通信ネットワークとコミュニケーション=== ここでは、情報通信ネットワークの性質とそのしくみについて扱う。 ====情報通信ネットワークの仕組み==== [[高等学校情報A]]、[[高等学校情報B]]では、情報通信ネットワークの重要性や問題点について学んだ。ここでは、 情報通信ネットワークがどのような仕組みで動いているかを説明する。 情報通信を行なうには、何らかの機具を用いて複数のコンピュータを接続する必要がある。これらを総称して、 [[w:通信機器]]と呼ぶ。代表的な例として、[[w:モデム]]、[[w:ADSLモデム]]、[[w:イーサネットカード]]などが あげられる。これらの機器はそれぞれ異なった原理で他のコンピュータに情報を伝達する。 <!-- モデムは、デジタルデータをアナログデータに変換し、そのアナログデータを電話回線を通して通信し、他の コンピュータに情報を伝達する手法である??。ADSLモデムは、用いる回線は電話回線であるが、モデムとは異なった 手法で伝達を行なう。最後に、イーサネットカードは専用のケーブルを用い、情報をデジタルデータで表わされる 電気信号で伝達する機具である。イーサネットカードは会社内などの比較的近距離の通信で用いられることが多く、 これによって作成されたネットワークを[[w:LAN]]と呼ぶ。 --> ここまでで、コンピュータ間で情報伝達を行なう物理的方法について述べて来た。ここからは、各コンピュータ間で デジタルデータが伝達できるものとして、それを用いてより安定した手法で通信を行なうためにはどのような 手法を用いるかについてまとめる。 まず、複数のコンピュータと通信するために、各コンピュータにそれらを識別するための番号をつける必要がある。 また、個々のコンピュータにつけた番号に加えて、コンピュータをネットワークにつないだときにだけ、 コンピュータに与えられる番号を用意することが望ましい。これは、例えばあるコンピュータを一旦ネットワークから 切り離して、別の組織に属するネットワークに接続しなおしたとき、そのコンピュータがその時点では 移された側の組織からネットワークに接続していることを、明確にしておくことがそのコンピュータの 場所を見つけ出す上で望ましいからである。 現在用いられている[[w:インターネット]]は、このような手法を用いてそれぞれのコンピュータを管理している。 まず、各々のコンピュータが持っている数値を[[w:MACアドレス]]と呼ぶ。この数値は、実際にはコンピュータではなく、 コンピュータの通信機器が持っている数値である。複数の通信機器を持っているコンピュータは複数のMACアドレスを 持っていることになる。次に、各々の組織に与えられ、コンピュータを接続する時に個々のコンピュータに 与えられる番号を、[[w:IPアドレス]]と呼ぶ。IPアドレスを個々の組織ごとに与えることは、ある1群のIPアドレスが 常にある機関に属することを保証することで、情報通信を簡単にする働きがある。 また、あるIPアドレスを持ったコンピュータに対して、より安定した方法で情報の伝達を行ないたいことがある。 例えば、通信機器としてモデムを用いたときには、何らかの理由で送った波形が乱され、 正しい情報が伝わらないことがある。このような場合、何らかの手法で発信元にその旨を伝達し、失われた情報を 再送してもらうことが望ましい。このような規格として、現在では[[w:TCP]]と呼ばれる手法が用いられている。 TCPはかなり複雑な手法であるので、ここでは詳しくは述べない。 ここまでで情報通信を行なう手法としてTCP、IPなどの手法を述べて来た。これらをまとめて[[w:TCP/IP]]と 呼び、この名称はインターネットで用いられる[[w:プロトコル]]として有名である。ここで、プロトコルとは、 情報通信を行なう形式のことを総称する場合に用いられる用語であり、英語の名詞protocol'手順、規約'から来ている。 ここからは、情報通信における個人認証や暗号化の重要性について述べる。インターネットを利用するときなどには、 重要な個人情報をネット上に流す必要がある場面がある。例えば、飛行機の予約やインターネットバンキングを用いる 時には、利用者が代金を支払う方法を指定しておく必要があり、そのために、利用者が誰であるかを知っておく必要が ある。デジタルデータは、その性質上複製が容易であるため、これらのデータを丁寧に扱わないと、相手に伝達する途中に 他人に読み取られる恐れがある。このため、例えその内容を見られたとしても、容易には内容を解読されない仕組みを用意することが望ましい。 このような仕組みとして、[[w:暗号]]を用いる方法がある。具体的には、送信するデータを暗号化し、送った先で 再び元の内容に戻すという手法である。暗号化の手法にはいくつかの有力な方法が知られている。このうちの 多くの手法では、利用者に[[w:パスワード]]の入力を求め、そのパスワードに何らかの変換を施した結果が、 対応するデータに記録されている結果と一致しているかどうかで、暗号を読むことが許可されているかどうかを 見る。そのため、暗号を用いるときには、簡単かつ推測されにくいパスワードを作成することが重要である。 パスワードは、ネットワークを挟んで相手が求めている人であるかを決めるためにも用いられる。 このような作業を個人[[w:認証]]と呼ぶ。このようなパスワードはネットワーク中に送信される前に 暗号化されることが望ましい。 ====情報通信の効率的な方法==== ここでは、情報の通信速度の単位や得られた情報の誤りを検出する方法、また情報の圧縮について簡単にまとめる。 情報通信速度とは、単位時間あたりにどれだけの情報を伝達できるかを表わす値である。単位としては、 [[w:bps]]を用いる。これは、 bit per second 'ビット毎秒'の略である。ここで、[[w:ビット]]とは、 2通りの情報を表わす量である。2通りの情報とは、0と1で表わされる情報のことであるので、 例えば1bpsは、1秒あたりに1つの0か1を伝達できるということを表わしている。コンピュータ間の情報伝達は、 0か1の信号を伝達することで行なわれるので、この単位は、情報伝達の速度を表わす単位としての役割を果たす。 次に、情報伝達によって得られた情報が正しいかどうかを検出する方法について述べる。情報伝達ネットワークを 通して得られた情報は、伝達の過程で変化してしまうことがある。これは、伝達される信号が電気信号であり、 外部的な要因から影響を受けることがあることから、避けられないことといえる。伝達された情報が 間違ったものとなってしまうことは望ましくないことであり、何らかの方法でこれらを検出する方法が必要となる。 実際には情報が誤ったものであることを検出する多くの方法が存在し、[[w:誤り検出]]の方法と呼ばれている。 ここでは、そのうちの簡単なものである、[[w:パリティビット]]の方法についてまとめる。 パリティビットとは、送信する情報の中の0または1の数を、常に偶数、または奇数に保つように、送信する データに1ビットのデータを加える手法である。仮に、送信された情報に1ビット分の誤りが現われたときには、 これは、元々が偶数であったなら奇数となり、奇数であったなら偶数となることから、何らかの誤りが生じたことが 検出されるのである。この手法は簡単だが、2つ以上の誤りが生じたときには誤りが起こったことを検出できない ことがあることに難点がある。より高度な誤り検出手法としては、[[w:CRC]]があげられるが、この手法の説明には かなり高度な数学を要するので、ここでは扱わない。 最後に、情報の圧縮手法についてまとめる。情報の圧縮とは、情報が持つ内容を変化させないで、情報の 大きさを減らす手法である。ここでは、簡単な情報圧縮の手法である[[w:ランレングス法]]([[w:en:Run-length encoding]])について まとめる。ランレングス法とは、同じ値が長く続いているときに、それをその値と値の数に置き換える 手法である。例えば、aaaaabbbbbcccccというデータがあったとする。このとき、データの数に注目して、 a5b5c5とまとめたとしても、データの指す内容は変わらない。これによってデータの大きさを減らすことが できたわけである。ランレングス法はわかりやすいが、同じ値がくり返されるような情報に対してしか 効果が得られない。より一般的な圧縮法については[[w:圧縮]]などを参照。ただし、これらの内容は高度な内容である。 ====コミュニケーションにおける情報通信ネットワークの活用==== ここでは、実際にインターネットを利用して、コミュニケーションを行なう手法について述べる。 インターネットを通じて提供されるサービスの主要なものとして、[[w:ワールドワイドウェブ]](WWW)、 [[w:電子メール]]があげられる。これらは、インターネットを通じて用いられることから、 どちらもTCP/IPをプロトコルとして用いている。しかし、これらの手法は、TCP/IPに加えて、 WWWでは[[w:HTTP]]、電子メールは[[w:SMTP]]、[[w:POP3]]などのプロトコルを用いている。 実際にはプロトコルは階層構造になっており、HTTPなどのプロトコルは、TCP/IPのプロトコルを 使用することを前堤とした上で、定義される手法である。具体的には、HTTPは、TCP/IPを用いて 接続の相手を確立した後、実際に伝達される情報などを定めている。例えば、Webページを送ってほしい時には、クライアントは GET / HTTP/1.0 という情報をサーバに送信する必要がある。このように、実際に情報を受け渡すときに、どのような指令を送るかを定めたのがHTTPプロトコルである。 TCP/IPは、情報を間違いなく送信する部分と、送信先のコンピュータの位置を探す部分を担当しており、どのような情報が送信されているかには 関係していないことに注意が必要である。プロトコルにおける階層構造のより詳しい説明については、[[w:OSI参照モデル]]などを参照。 ここまでで、WWWと電子メールがそれぞれのプロトコルに従って情報伝達を行なうことについて述べた。 プロトコルに従うためには、これらのプロトコルに従って情報を発信するソフトウェアを手に入れることが 望ましい。具体的にはこれらのソフトウェアは、WWWに対しては、[[w:Webブラウザ]]、 電子メールに対しては、[[w:メーラ]]、[[w:MUA]]などと呼ばれる。 実際にはプロトコルを扱うだけでなく、読みこんだ情報を表示したり、メールを整理したりするための 機能も追加されるため、これらのソフトウェアは高度なものとなりやすい。 オープンソースのWebブラウザには、有名なものとして[[w:Firefox]]があげられる。 <!-- Sleipnirは、オープンソースだっただろうか ... 。というか、ここにあげた方がよいのだろうか ... 。 --> また、メーラとしては[[w:Thunderbird]]、[[w:Evolution]]が有名である。 ここでは、Firefoxと、Thunderbirdを用いて、その使用法について簡単にまとめる。ここではこれらは既に 導入されているものとする。導入の情報については、後述の付録を参照。 Firefoxを起動すると、ホームに登録されているWebページが表示される。実際にはこのWebページを取得するために 既に、HTTPプロトコルを用いた情報伝達がなされていることに注意。与えられた[[w:URL]]に存在する情報を取得するには、 上方にあるバー内に、対応するURLを書きこめばよい。例えば、 http://en.wikibooks.org/wiki/Main_Page などを試してみよ。これによって、対応するコンピュータにHTTPプロトコルを 用いた情報が送信される。ここで、相手方のコンピュータを指定するには本来IPアドレスを指定する必要があったことに 注意が必要である。上では人間にも読める文字列を用いたので、これをIPアドレスに変換する機構が存在することになる。 この様な機構を'名前解決'と呼び、これを行なうサーバを[[w:DNSサーバ]]と呼ぶ。 <!-- DNSはプロトコルの1種であり、IPを用いた通信で補助的に 用いられる --> ここまででHTTPプロトコルを用いて情報を取得する方法について学んだ。実際には、ブラウザには他にも機能が存在する。 例えば、既に訪れたWebページを記録しておく機能や、よく閲覧するWebページを登録しておく機能などがある。<!-- しかし、 これらは単にコンピュータ内の記憶装置に指定されたWebのURLを記憶しておくだけの機能であり、複雑な機能ではない。--> それ以外にもブラウザには、[[w:HTML]]や[[w:JavaScript]]を解釈するなど多くの機能があるが、ここでは詳しくは扱わない。[[Firefox]]などを参照。 <!-- [[Firefox]]は書かれるだろうか ... ? やはり安易な赤リンクはやめた方がいいだろうか ... ? --> ここからは、Thunderbirdについて解説する。Thunderbirdはメールの送信と受信を行なうことが出来るが、実際に メールの配信を行なうのは、メールサーバと呼ばれるプログラムであり、Thunderbird自体はその機能を持っては いない。実際にThunderbirdが行なっているのは、メールサーバが受け取ったメールをクライアントのコンピュータまで 取り寄せる作業や、クライアントが送信したいメールをメールサーバに送り届ける作業である。 これらの作業にはそれぞれPOP3プロトコルとSMTPプロトコルが対応しており、それぞれのプロトコルに対応する メールサーバの名称(もしくはIPアドレス)をThunderbirdに与えておく必要がある。ここではそのような作業が 既に行なわれているものとする。 Thunderbirdには、文章を作成する機能も含まれており、それを用いて送信する文章を作成することが出来る。 文章の作成が終わったら、送信先の[[w:メールアドレス]]を入力する。メールアドレスの整理にアドレス帳という 機能を用いることもできるが、ここでは扱わない。メールアドレスの入力が終わったら、メールの送信を行なう。 メールの送信はSMTPプロトコルを通じて行なわれる。Thunderbirdは、入力された文章とメールアドレスを用いて、 プロトコルに従った情報を作成し、指定されたメールサーバに送信したいデータがあることを知らせる。 このとき、SMTPサーバは認証を行なうよう求める。これもSMTPプロトコルによって定められた手順である。 認証には自分のIDと、パスワードが必要である。IDとパスワードも正しい形式と順番で送信しないとメールサーバは 応答しない。しかし、その作業はThunderbirdが代行するので、単にIDとパスワードの欄に与えられた情報を 書きこめばよい。パスワードが正しいときには、サーバは送信したい情報を送信するよう促すので、Thunderbirdは、 これを送信する。これでSMTPプロトコルを用いたメール送信は完了である。 自分に来たメールを閲覧するときにもほぼ同じ手順が用いられる。POP3プロトコルは、認証を行ない、それが 成功すると、対応するIDに送信されたメールをクライアントに向けて送信する。これを受信することがThunderbirdの行なう作業である。 他にも、メーラには送られて来たメールがHTML等で書かれていたときにそれを正しく表示するなどの機能が含まれている。 詳しくは[[Thunderbird]]などを参照。 <!-- ここまででWWWと電子メールの簡単な使い方について述べた。 --> ===情報の収集・発信と個人の責任=== ここでは、情報発信に伴う責任についてまとめる。また、収集した情報を表計算ソフトウェアを用いて分析する手法についても扱う。 ====情報の公開・保護と個人の責任==== 今日では情報機器を用いることで、個人が広く情報を発信することが可能になって来た。しかし、情報を発信することが簡単に なったとはいえ、発信には多くの責任が伴うことを忘れてはならない。間違った情報や不正確な情報は、社会を混乱させることが あり得るからである。ここでは、情報発信に伴う責任について簡単にまとめる。 まず最初に、情報の中にはそれを秘密にすることが要求されるものがあることに注意する必要がある。例えば、クレジットカードの 暗証番号などに代表される、パスワードに類するものは、その最たる例である。しかし、それ以外にも道義的にも[[w:法]]的にも それを出来る限り秘密にすることが当然とみなされるものもある。例えば、ある人の名前、年令、職業などの情報は[[w:個人情報]]と呼ばれ、 不特定多数の他人に知られないように出来ることが求められる。これは、自分の情報を自分でコントロールできることが個人の権利であるという 考え方から来ている。このような権利を、[[w:プライバシー]]の権利という。 このような情報を発信したいと思うときには、必ず相手の意思を確認し、また必要がない限り個人情報の発信は避けるようにするのがよい。 また、他人の著作物をデジタルデータの形で手に入れたときに、これを公開することは著作物の作者の[[w:著作権]]を侵害する。 著作権は著作物の作者に対して与えられる権利であり、著作物が不特定多数の人間の手にわたらないようにすることが出来る 権利である。この権利は著作物に対しては常に存在するため、他人の著作物を公開することは権利の侵害とみなされ、[[w:犯罪]]となる。 そのため、他人の著作物は絶対に公開してはならない。 また、このような情報以外でも、みだりに不正確な情報や虚偽の情報を発信することは、他人の迷惑となる意味でも、 自身の信用を失わないためにも、避けた方がよい。また、特に正確かどうかが定まらない情報の中でも、より偏ったものの見方を する情報を公開することも、自身の信用を失うことから避ける方がよい。例えば、自分の友人の性格や容貌などに対して、 一面的な見方で評価を行なうことは、他人との軋轢を引き起こすことから避けた方がよいだろう。ただし、他人に対して一切の評価を 行なわないことは現実的ではないので、どの程度の情報発信を許すかは各々の場合による。実際にはお互いの間で話し合いを行ない、 どの程度までが許容される範囲であるかを定めるのがよいだろう。ただし、ネットワーク上のコミュニケーションでは、文字以外の 情報を伝達することが困難であるため、より慎重に言葉を選んでコミュニケーションを行なわないと、いさかいにつながると予想されることが 近年の事件から知られるようになって来ている。このため、ネットワーク上でのコミュニケーションは慎重に行ない、判断に迷ったら 出来る限り安全な方を選ぶ方が無難といえる。 ====情報通信ネットワークを活用した情報の収集・発信==== ここでは、情報ネットワークを用いて、自分が探したい情報を求める方法について述べる。更に、表計算ソフトウェアを用いて、 得られた情報を分析する手法についても学習する。 ===情報化の進展と社会への影響=== ここでは、社会で実際に用いられている情報システムについて扱う。また、情報化社会の発展に伴い、どのようなシステムが必要となるかについて議論する。 ====社会で利用されている情報システム==== ここでは、実際に用いられている情報システムをいくつか選び、その概略についてまとめる。 まず最初に、[[w:POSシステム]]について扱う。POSシステムとは、小売り店などで販売された商品について、売れた商品の種類、価格、時間、客層など のデータを集め、売れ筋の商品、死に筋の商品を 把握するためのシステムである。これらのシステムはコンビニエンスストアなどで用いられていることで有名であり、限られた売場面積しか持たない コンビニエンスストアで、より売れる商品と品数を把握する上で、大きな役割を果たしている。 POSシステムは、店で扱うそれぞれの商品のデータベースを作成し、どの店でどれだけの商品が販売されたかを把握することを目的とする。実際には、 どの店でどの商品が売れたかを調べるために、商品のバーコードなどを元に、売れた商品の種類をデジタルデータとし、取り入れたデータを扱う コンピュータによって、売買の日時や店の位置などとまとめて、売り上げを扱うデータベースとする。作成したデータベースは、 そのまま販売した店で使用することも出来るが、実際には情報通信ネットワークを通じて、いくつかの店からの情報を中心となるコンピュータに収集 する場合が多い。この時、集められたデータは売れ行きがよい商品とそうでない商品を見出すために用いられる。 このシステムの利点は、本来様々な連絡をくり返さないと集められないはずの商品データを、半自動的に1か所に収集できることにある。これによって、 より正確に消費者の[[w:ニーズ]]をとらえた、商品の注文、開発を行なうことが出来る。 情報システムとしてのPOSシステムは、[[w:データベース]]や情報通信ネットワークを用いて作成する。 <!-- 仮に情報の入力方法が知られたなら、それらを用いてデータベースを作成することは 比較的容易である。一方、 --> <!-- バーコード等を扱う機器については、対応する[[w:デバイスドライバ]]が必要となるため、開発はやや難しい。--> データベース<!--、デバイスドライバ-->については[[高等学校情報B]]などを参照。 <!-- 例えば、[[w:プログラミング言語]][[w:Python]]を用いて、データをファイルから読みこみ、それを整形してデータベースとしてまとめるプログラムを書くことは、 それほど難しい作業ではない。 しかし、プログラミングの詳細を扱うことはここでの主旨ではないので、ここではそれについては扱わない。 Pythonについては、[[高等学校情報B]]、[[w:Python]]を参照。--> 実際にPOSシステムを作成するときには、データベースの速度性能や、データベース内に貯えることが出来るデータの量などに厳しい制限があることが多いため、 要求通りに動くPOSシステムを作成することはそれほど簡単な作業ではない。また、実際にデータベースを用いるときには、商用の高性能な データベースソフトウェアを用いることが多いため、費用の面でもそれほど安価にはならないことが普通である。そのためこれらのプログラムの 作成作業は、専門のITベンダが代行することが普通である。 次に、WWWを用いた、ショッピングシステムについて扱う。WWWは[[w:ワールドワイドウェブ]]の略であり、HTTPプロトコルを用いて、情報の検索などを行なう サービスの事を指す。ショッピングシステムとは、特にブラウザを用いて商品の画像などを頼りに買い物を行なうことができるようにすることを 目的としている。代金の支払いには、クレジットカードなどを用いることが多い。ショッピングサイトの非常に有名な例として http://www.amazon.co.jp が あげられるが、現在では大手の小売り店の多くが、このようなサービスを行なっている。 ショッピングシステムの導入には、多くの技術が必要となる。まず最初に、利用者の希望に応じて扱う情報を変化させる手法について述べる。 ショッピングサイトの作成には、商品のデータを商品の画像も含めて、データベース化することが必要である。 サイト側は各々のデータを利用者の希望に応じて引き出し、対応するページを表示することが必要となる。また、利用者が探しているものの名前が既に わかっている場合には、サーバ側は商品の中から対応する名前の商品を検索し、クライアントに提示できることが望ましい。 特に検索を行なうためには、サーバ側はブラウザ側から受け取った情報を元にして、情報の検索を行なう必要があることがわかる。 実際、サーバと連係して働き、データの検索などのサーバが提供しない機能を提供するソフトウェアが存在する。ソフトウェアが存在する。 例えば、[[w:CGI]]、[[w:PHP]]、[[w:JSP]]等の技術がこの例である。 このようなプログラムに対して、サーバはクライアントから受け取った情報を提供する。受け取ったプログラムは、受け取ったデータに対して所定の 動作を行ない、その結果をサーバに戻す。結果を受け取ったサーバは、それを用いて、クライアントのブラウザに送信するための情報を 生成し、それをクライアントに送信する。このような一連の動作によって、クライアントは自分が欲しい情報を、的確に得ることができるのである。 このようにサーバ側のプログラムによって生成されたページを、'動的に生成'されたページと呼ぶ。一方、常に変化しない情報を扱うページを、 '静的に生成'されたページと呼ぶことがある。 ここまでで利用者の希望に応じて扱う情報を変化させる手法について述べた。ここからは、利用者の[[w:認証]]を扱う方法について述べる。 HTTPプロトコルは、クライアント側からの送信とサーバ側からの返信をくり返すことを定めたプロトコルである。ここで、クライアントから 送信できる情報には、ページの場所以外に、サーバに与えたい[[w:変数]]を送信することも許可されている。そのため、この情報を用いて、 あるページを利用した利用者が、サイト内の別のページを利用した利用者であることを知ることが出来る。例えば、ある商品を購入することを 決めた利用者が、実際に購入の手続きを行なうためのページを訪れたものとする。この時、ある商品の購入を決めて、購入の予約を したときに限って送信される変数を見ることで、その人が確かに商品を購入する予定の人であることがわかる。このように、 ページの利用者がどの利用者であるかを知るための手法を[[w:認証]]と呼ぶ。 上の方法は、利用者が一旦他のサイトを利用してから戻って来た場合には使用できないという欠点がある。現在多く用いられている 方法では、認証を行なうために[[w:クッキー]]([[w:Cookie]])を用いる。クッキーは、サーバ側からクライアント側に送信され、クライアント側が コンピュータ上に保存するよう定められている小さいデータである。ブラウザは対応するクッキーを送って来たサーバにアクセスするときには 常に、クッキーを送信するよう定められている。このことによって、例え他のサイトを経由してからアクセスしたとしても、 その人が確かに対応する利用者であることが知られるのである。クッキーはショッピングサイト以外でもログイン、ログアウトを用いるサイトでは よく用いられる。例えば、[[w:MediaWiki]]は、認証にクッキーを用いるソフトウェアの例である。 最後に、我々が普段用いているパーソナルコンピュータについてより詳しく述べる。これらのコンピュータは[[w:サーバ]]用途のコンピュータと比較して、 [[w:クライアント]]向けコンピュータと呼ばれることがある。我々が用いているコンピュータは、[[w:CPU]]、[[w:メモリ]]、[[w:ビデオカード]] などから構成されている。適切なプログラムを用いることで、我々はCPUを自由に扱うことが出来る。しかし、これらの命令は電気信号であるので、 我々が実際に送られている命令を読み取ることは容易ではない。そのため、CPUに対する命令を送るための機具として、[[w:キーボード]]や[[w:マウス]]などの 機具が用いられるようになった。これらがCPUに送る命令に対して、我々が望む通りの動作を起こさせるプログラムが実際に作成されており、 このようなソフトウェアを[[w:OS]]と呼ぶ。我々が用いているコンピュータには既にOSがインストールされているものが多い。しかし、OSが インストールされずに販売されているコンピュータも少数ながら存在し、それらのコンピュータを用いるときには、まず最初にOSを導入することが 普通である。よく用いられるOSとして、[[w:Windows]]、[[w:Mac OS]]、[[w:Linux]]がある。ここでは、主にLinuxを例に取って説明する。これは、Linuxの [[w:ソースコード]]が公開されており、ソフトウェアの学習に用いることができることと、Linuxが基本的に無料であり、極めて高性能であることによる。 コンピュータを起動するとき、Linuxは、コンピュータに接続されている機器について調べ、それらを正常に用いることが出来ることを確認する。 この手順が正常に終了すると、Linuxは利用者に対して、利用者が実際に行ないたい作業をコンピュータに与える ように促す。最も簡単なシステムでは、[[w:シェル]]という1群のソフトウェアがこの目的で用いられる。シェルは、コンピュータに既に インストールされているソフトウェアに関する情報を貯えており、それらの起動、複写、削除などを行なうための基本的な機能を備えている。 シェルは、キーボードから与えられた文字列を適切なルールで解釈することで、利用者からの命令を受け取っている。文字列で与えられた命令を 解釈するためのプログラムは、[[w:パーサ]](字句解析器)と呼ばれ、高度な計算機技術の例として知られている。詳しくは、[[計算機科学]]などを参照。 <!-- 現在でもシェルは、メモリが少なく後に述べる[[w:GUI]]を用いるのに不適なコンピュータでよく用いられる。また、シェルはGUIと比べて コンピュータからの対応が高速になりやすいため、ある程度コンピュータに慣れた人間は、好んでこのソフトウェアを用いることが多い。 実際にはGUIで提供されていない機能を用いるためにはCUIで操作するしかない。しかし、現在のGNOMEでは非常に多くの機能が提供されていることも 事実ではある。明らかにCUIの方が有利な例として、多くのファイルがある中で、目当てのファイルの頭文字が分かっているときに、 Tab補完を用いて、そのファイルを指定することができることだろう。 と思ったら、最近のノーチラスはアルファベットキーを押すと、頭文字に対応したファイルにジャンプしてくれることがわかった。 こうなるとCUIにこだわる意味がなくなってしまうのだが ... 。 --> 一方、現在のビデオカードを用いると画面に描かれる内容を自由に制御することが出来るため、実行したい命令のそれぞれを[[w:アイコン]]を用いて 映像化し、それらを[[w:マウス]]で[[w:クリック]]することで、対応する命令を実行するという情報伝達の手法が研究された。 これらの手法を、[[w:GUI]](Graphical User Interface)と呼ぶ。GUIは、現在のクライアント向けコンピュータでは標準的に用いられており、 初心者でもコンピュータを操作することが容易になる手法として知られている。 Linuxでは、[[w:X Window System]]と呼ばれるソフトウェアを用いて、GUIを実現することが多い。X window は、OSとは異なるものの、 キーボードやマウス、ビデオカードを扱って入力の受け付けと画面への表示などを扱うソフトウェアである。実際にビデオカードを用いる時には、 X windowは、画面を細かい点の集まり([[w:ピクセル]]と呼ぶ)として把握し、それらのピクセルに対応する情報をビデオカードに送るよう、CPUに命令する。 <!-- ビデオカードとCPUの間の情報転送はPCIバスではなくより高速なバスを用いているらしい。 --> 表示する情報を上手く作ることで、ウィンドウ、アイコンなどの絵を描くことができる。これらのアイコンに対して、実行したい命令を 当てはめることで、コンピュータの動作を制御できるわけである。 実際にはアイコンを用いて、コンピュータを操作するために必要十分な情報を提供することが重要である。このような一群のソフトウェアを [[w:デスクトップマネージャ]]と呼ぶ。ここではそれらの詳細には立ち入らないが、[[w:GNOME]]、[[w:KDE]]の両者が有名である。 特に、一般業務でよく用いられる機能を実現したソフトウェアを、[[w:アプリケーション]]と呼ぶ。これらは、シェルを用いて起動する事も出来るが、 GUIを用いて起動できるようにもなっていることが普通である。主要なアプリケーションとしては、Webブラウザ、メーラ、ワードプロセッサ、 表計算ソフトウェア、プレゼンテーションソフトウェアなどがあげられる。これらのソフトウェアは多くの場合GUIを用いて利用者との情報伝達を行なうため、 X window システムを起動した上で、用いられることが多い。 <!-- lynxなどは違うが ... 。 --> Linuxで用いられるアプリケーションとしては、ブラウザとしては[[w:Firefox]]、メーラとしては[[w:Thunderbird]]、 それ以外にワードプロセッサ、表計算ソフトウェア、プレゼンテーションソフトウェアとして、[[w:OpenOffice]]が有名である。これらの ソフトウェアはどれも[[w:オープンソース]]の手法で開発されており、無料で手に入れることが出来、どれも非常に高機能であることが 知られている。 ====情報化が社会に及ぼす影響==== 情報システムはこれまでにも多く作成され、我々の生活の様子を変えて来た。これからも様々な情報システムが構築され、我々の 生活に変革を迫っていくことが予想される。我々はこれらのシステムのあり方に興味を持ち、これらのあり方について考えることが求められるのである。 *課題 情報化が社会にもたらす影響について、情報通信ネットワークを用いて調べ、それについて考察せよ。 <!-- いかにも収拾がつかなくなりそうな課題だが大丈夫なのだろうか ... 。 --> 2nmgsl6jc7j2idsk475hqp5zfa9shww 0 4250 205915 205896 2022-07-27T15:03:55Z Honooo 14373 /* ストーリー制作、そして順序 */ 第４段落まで再編集。4/5。 wikitext text/x-wiki <div class="pathnavbox"> * {{Pathnav|ゲーム}} * {{Pathnav|工学|情報技術|プログラミング}} </div> == 概観 == このWiki参考書では、コンピュータを用いた[[w:ゲーム]]のプログラミングを扱います。つまり、いわゆる「テレビゲーム」や、[[w:コンピュータゲーム|コンピュータゲーム]]に関する記述についてです。 ここでは家庭用のパーソナルコンピュータで扱える範囲の事柄、それらのゲームソフトをつくるためのプログラミングについて議論します。必要に応じて家庭用ゲーム機の話題にも触れますが、あくまで派生的なものです。本書はプログラミングの教材であるので、大多数の読者が最初にプログラミングで触れるであろうパーソナルコンピュータでのプログラミングを、特にことわらないかぎりは想定しています。 用語に関して、コンピューターゲームの世界独自なものもあるでしょうから、適宜『[[ゲームプログラミング/コンピュータゲームの種類]]』などを参照してください。 == 本書の目的 == この教科書『ゲームプログラミング』の目的は、題名にもあるとおり、プログラミングによってゲームを作るための技術の参考資料を目的としています。 ゲームクリエイターやゲームデザイナー（絵描きではなくゲームの設計者のこと）のためではなく、プログラマーのための教科書です。 したがって本書では、ゲームとは関係の少ない一般IT企業での仕事のしかたについての記述もあれば、製造業系の組込ソフトなどに関する概要的な記述もあります。 なぜなら本書はゲームクリエイターではなく、たまたま何らかの理由でゲームを作っているプログラマーのための教科書だからです。たとえゲーム会社を退職しても、他の一般IT企業に転職してもプログラマーとして応用できることなども目指して本書は書かれています。 従って、紹介する話題が、かなりIT系、テクノロジー系の話題に片寄っています。本書で紹介するクリエイター論やデザイン論は、派生的なものにすぎません。 ;本書を扱う上での注意点 特にことわりのないかぎり、本書ではC言語でのプログラミングによってゲームを作りたい読書を念頭に説明しています。 だから、ゲームの生産効率性を無視してでも、本来ならRPGツクールのような開発ツールを使ったほうが早いシンプルなゲームの場合ですら、本書ではC言語または他のプログラミング言語での開発にこだわった方法を説明している場合もあります。 ;その他、本書について このページとそのサブページだけを見ていると本書は「ゲームクリエイトの教科書かな?」と捉えられるかもしれませんが、 しかしこのページとは別に本wikibooksには「[[プログラミング]]」というページがあり、そこではC言語やJavaなど代表的なプログラム言語のwiki教科書にリンクしています。ゲーム限定の話題ではないですが、プログラミングのコードについても、そちら『[[C言語]]』や『[[Java]]』やなどの教科書のほうが（実際に動作するコードの量が）充実しています。また、Visual C++ での画面出力については『[[Windows API]]』に入門的な説明があります。 本書『ゲームプログラミング』はそういったプログラミング教科書一覧の一部でもあります。C言語やWindows API の教科書では、これをどうやってゲームのプログラミングに応用すればいいか説明できないので（本wiki『[[C言語]]』はけっしてゲーム目的のページではないので）、ゲームの実際としてプログラミングの話題を切り離すために本書『ゲームプログラミング』は存在しています。 なので本書にゲームデザイン論やクリエイター論などの内容の充実は期待できません。 本書『ゲームプログラミング』は現状、プログラマー目的以外には対応できないかもしれません。もしプログラマー目的以外の無料のwiki教科書が欲しい方は、現状では、自分で本wikiに加筆するか、あるいは本書『ゲームプログラミング』とは別に新規Wiki執筆を検討していただきたい。 == ゲームを作りたいな、よし、ゲームを作ろう。でも… == ===しかし自分の本当の目的ってゲーム作り？=== 「ゲームを作りたい」と思ったのなら、まずはあまり細かい難しいことは考えず、実際に作り始めてみるのが一番いいと思います。もちろんプログラミングについてほとんど何も知らないのなら、ある程度の勉強は必要ですが、ある程度の知識があるのなら、プログラミングの技量や知識の充実を気にするよりは、実際にゲームの完成を目指してプログラムを書いてみるのが一番いいようですよ。その過程でプログラミングの学習や経験は積んでいけますしね。JavaScriptやPython、無料でプログラミングに取り組める環境も、今現在では充実しています。 しかし、ゲームをプレイするのが好きだからと言って、ゲームを作る、までが本当に自分が好きかどうか、試しに少し作ってみたら、少し考えてみるといいですね。 例えば読者の中には、「私はRPGがすき」という人も多いでしょう。 RPG が好きという事はおそらく、よくRPGの題材になる西洋ファンタジーのストーリーや世界も好きという場合が多いでしょう。そして一方で現実のコンピューターRPGで魅力的に提供される、イラストや音楽が好きという場合もあります。 実際のゲーム業界の人々も、ゲームを彩るイラストレーションや音楽がいかに重要な要素かを語っています<ref>川村元気『理系に学ぶ』、ダイヤモンド社、2016年4月21日第1刷発行、P85</ref>。 さて、ここで問題なのですが、「ゲームを作りたい」と貴方が思っていたとして、あなたが本当に作りたいのはゲームなのか？あるいは本当はイラストが描きたかったり、音楽を作りたいのではないか？ …というのは、ゲームというのは総合的な分野ですから、イラストや音楽はその要素として確実にありますが、それ以外、プログラミングやシナリオなど、様々な創作や創造が必要で、全ての作業量はかなり多いものになるでしょう。 そしてゲーム、コンピューターゲームにはゲーム独自の世界観があって、現実や小説や映画とは違う、独特の法則に支配された世界を作る必要があります。ある意味リアリティを持たない、リアリティから外れた世界です。だから、小説のようなリアリティにこだわるなら、ゲームは不向きかもしれません。 ゲーム作り始めの時点では、これらの判断は明確でなくても勉強目的でも構いませんが、しかその内「自分は本当にゲームを作りたいのか? Yes or no?」という疑問への答えが必要になるときがくるかもしれません。 試しにゲームを作ってみて、もし自分の本当の目的がゲームでないと分かったなら、それ以外の活動に移るのも、取る道の選択肢でしょう。 ;給料は安い 職業として、商売としてゲームを作る場合、ゲームプログラマーの給料は洋の東西を問わず、安い事が知られており、書籍などでも言及されています。たとえば『CAREER SKILLS　ソフトウェア開発者の完全キャリアガイド』（ジョン・ソンメズ 著）という欧米人のプログラマーの書いた本には、アメリカのゲーム業界ですらハードワークの割に賃金が低い事が記載されており、もし給料の高い仕事につきたいならウォールストリート（※米国の金融ウォール街のこと）のための仕事をするべきだと書籍中で指摘しています。 日本でも同様にゲーム業界の報酬が低いことは知られており、多くのゲーム会社の伝記漫画でも、よく語られています。 アニメーション業界と比べたら、ゲーム業界のほうが報酬が高いことは事実かもしれませんが、これは実は恐ろしいことに、アニメーション業界の報酬が異常に低いだけで、アニメーション業界よりはましだけど、結局は…というのが現状でしょう。 === 同人ゲーム以外の発表の場 === 2001年ごろの日本はネットを活用した同人ゲーム黎明期、フリーゲーム黎明期で、実験的な時代でもあり、多くのイラスト愛好、創作者や音楽創作者がゲーム制作に手を染めていたようです。この頃、まだイラスト投稿サイトや小説投稿サイトといったものは無かったか、あったとしても小規模でマイナーなものでした。 しかし2010年のあたりから各種の投稿サイトが普及したことにより状況は変わり、むしろ現在では、小説やイラストを発表したい人はそのジャンルの投稿サイトに直接アクセスしたほうが早く、そのためゲームを通して発表するのは人によっては廻り道かもしれません。 それをわかったうえで、それでもゲーム制作に身を投じるかを考えた上で、「よし、自分はゲーム制作をしよう」と思えるなら、ゲーム制作をするのが良いでしょう。 実際、今現在の作曲家やイラストレーターは、ゲームに関わったとしても、専門家として楽曲やイラストを提供するという立場に過ぎない場合もあり、自分自身が主体になってゲーム制作をする人は、プロアマ問わず少数派のように見えます。 同人ゲームの世界でも現在は（2021年頃に記述）、プログラマー系の作者が圧倒的に多い様です。 しかし、専門外の人だからこそ、メディアミックス的な意外な視点で新しいものが作れる可能性もあるかもしれません。コピーライター、作家の糸井重里が、マザー2の企画にたずさわった例もあります。しかし、あくまで「可能性」であり、成功はけっして保証されてはいないので、読者の自己責任でお願いします。 今現在のゲーム専門学校のカリキュラムはプログラミングが主体です。CGの授業は、週に2時間程の様。一方でゲームCG、或いは、一般CGに特化した学科もある様です。 あるWikibooks編集者Aは、もしイラストを描きたいなら、イラストの世界で描くのが安全、と考えています。ゲームプログラミングについては、プログラムを書ける人は絵コンテも描けそうだし、基本的にある程度の作図的なイラストを描ける人は多いだろうから、別にプログラミングに専念しろとは思っていません。 さて、読者がゲーム制作を職業として目指すのかどうかはともかく、とりあえず、ゲーム業界の状況を知っておくのが有用でしょう。 結局商業界の状況が権威をもってその分野を支配しているのがこの社会の基本なので、趣味でも職業でも、業界周辺のことを知っておくのは得ることが多いはずです。 文献『レベルデザイン徹底指南書』では、現実世界で自分が新しいスキルを1つ覚えたら、古いスキル1つはどれか忘れる必要があることを説いています<ref>大久保磨『レベルデザイン徹底指南書』、2016年12月14日 初版 第1刷発行、P81</ref>。著者は、最初はグラフィッカーでしたが、しかしプランナーに転職したので、グラフィック関係の技能は仕事では「忘れて」しまった、という内容を述べています。ただし、比喩的に「忘れる」とは言っていますが、実際には忘却し無くなってしまったわけではなく、仕事では時間の都合により両立できないので、グラフィック関係の技能は例え話で「忘れた」、のであり、現実にはグラフィッカー時代に培った観察眼をプランナー時代の現在でも活用している、と、書籍中では述べられています。 このことは職業、あるいは技能とは一般的にそういうもの、と考えることができるでしょう。 {{コラム|漫画家大塚志郎のアドバイス| 同人ゲーム界では、ゲーム制作と、イラストまたは作曲などを一人で兼ねている作者も、ある程度は居ます。一方ネットの世界には様々な簡単に利用できるフリー素材もあるので、イラスト作画や作曲をしなくてもゲーム制作は可能ですよね。 一人でイラスト作画や作曲をしながらゲーム制作をするのはある意味マルチタレントだとも言えますが、現実にその創作をしている人たちは、かなり年長のこの分野の熟練者が多いようです。若い19歳ぐらいの頃に、それらマルチジャンルを両立するのは、一般にかなり困難なことだと思われます。 漫画家の大塚志郎は、漫画家を漫画創作の手本にするならデビュー時代を手本にするのが良い、と、漫画家向けの技法の教育漫画で語っています。 大塚は、漫画家の人生のうちで、これからデビューを目指している新人に近い境遇にあるのは、ヒット後の漫画家の生活状況ではなく、まだ無名･マイナーな時代の態度・生活だ、と描いています。成功後の熟練した漫画家より、若いデビュー直後の作家をお手本にするのがいいだろう、という主張ですよね。 さて、それでもデビュー時代から複数ジャンルの同人活動を均等に兼業する意思が硬いなら、それはそれでひとつの考え方ですが、上述のリスクを知っておく必要があるでしょう。 }} ===ゲーム業界は産業のエンジン役?=== かつてはゲーム産業が、日本のIT産業やデジタル家電産業の中心的・牽引（けんいん）役であった時代がありました。しかし、2010年以降、この考えは当てはまらなくなっています。 PlayStation2あたりまでの時代は、経済評論誌の未来予想でも、「もしかしたら今後、家庭用の据え置きゲーム機がパソコンの代替品として、家庭のリビング家電の標準品になるかもしれない」という予想があった。ゲーム産業がそのような牽引役として、経済界から期待されていました。ソニーが国産CPUをプレステ2〜3に搭載したり、WindwosのマイクロソフトがXBOXでゲーム機に参入したり、そういう時代です。 しかし2020年代の今は違います。結局、2020年代のゲーム機に使われてる技術や部品は、パソコン用の部品や技術の流用、ゲーム機のCPUも、今やインテルなどのパソコン用CPUをゲーム機でも使っています。 もはや現代は、ゲーム業界は、産業のエンジンではないようです。 ですから今現在、新しい技術に興味ある人は、ゲームにこだわらず、直接的にその技術を勉強し改良したほうが近道です。 たとえば、インターネット技術を使って何か新しい事をしたいなら、ゲームを作るよりもwebアプリやサーバーwebサービスを作るべきだし、目的のネットワーク用ソフトウェアをそのまま制作したほうが早いし確実です。 古い経済知識の先入観にとらわれず、無理にゲーム制作にこだわらないほうが、自分自身の技能やキャリアも開けていくでしょう。 2010年に出版された商学書籍『メイド・イン・ジャパンは終わるのか』には、「しかしながら、ファミリーコンピュータで世界に攻勢をかけ、その後圧倒的な強さを誇っていた日本の家庭用ゲーム産業も、90年代末からはその競争力にかげりがみえはじめた。日本の国内市場は伸び悩み、成長率は鈍化傾向にある（図表7-3）。」とあります<ref>青島矢一ほか『メイド・イン・ジャパンは終わるのか』、東洋経済、2010年8月12日発行、P.263</ref>。 その「図表7-3」の統計値によると、 :ファミコン発売の1993年には2268億円、 :スーファミ発売の1990年には2430億円、 :プレステ1発売の1994年には3882億円、 :1995年には急成長して4769億円、 :1997年には4795億円で、ほぼこの頃がピークであり、 :2000年には3768億円にまで低下（プレステ2の発売年）、 :2005年には3151億円まで低下（XBOXの発売年）、 である。（青島らが『レジャー白書』、『情報メディア白書』、『月刊トイジャーナル』、『CESAゲーム白書』などをもとに作成した図表の統計値です。） <!-- ところで前編集者Sさん，これって正確には何の数字，金額なの?それを後で書き足しておいてほしいんだけど…。あれかな？一年のこの国のゲーム産業の売上高？ --> また、2010年の時点の商学研究では、1997年を境に、ゲームソフト市場で競争する企業数が増加傾向から減少傾向に転じた<ref name="m289">青島矢一ほか『メイド・イン・ジャパンは終わるのか』、東洋経済、2010年8月12日発行、P.289</ref>、とも言われています。 書籍『メイド・イン・ジャパンは終わるのか』にも、引用文「家庭用ゲームは日本がその本格的立ち上げを主導し」<ref name="m91">青島矢一ほか『メイド・イン・ジャパンは終わるのか』、東洋経済、2010年8月12日発行、P.91 </ref>と書かれているぐらいで、1990年代は日本のインパクトが強かったようです。 なお、携帯電話の分野で、日本は国際的な地位を喪失したのに対し、デジタルカメラとゲームは「現代」（参考文献の著作時2010年ごろ）でも日本が主要な地位にある<ref name="m91" />。 {{コラム|ゲームが産業の牽引役だと語った人物| 1998年頃、アニメ評論家の岡田斗司夫が、未来予想の一貫として、「これからゲーム機が、（パソコンではなく）家電の中枢になるだろう」というような内容の未来予想をしていました。たしか、岡田の著書『東大オタキングゼミ』（自由国民社、1998年）で、このような未来予想が読めます。岡田の東大での講義を加筆修正してまとめた書籍なので、実際の講義はその数年前に行われていたのだろうと思います。 岡田の東大での講義は東大生のその後の進路、官僚や大企業のビジネスマン達に大きな影響を与えただろうし、若手新進評論家として、この国の政治・経済人達も、その言論を参考にしただろう。 実際、2008年（リーマンショックあたり）くらいまでの日本の家電業界の投資は、ソニーがゲーム機のCPUを作ったりと、岡田の予想を参考にしているような面もありました。 ですが実際の2001年以降の家電業界の結果は予想とは少し外れました。まず :* そもそも、冷蔵庫もエアコンも全然デジタル化（IoT化）されず、家電のほとんどが外部からのコンピュータ制御を必要としない状況。 :* 個々人が持ち歩いているデジタル家電は、携帯ゲーム機ではなくスマホになった。 :* パソコンは多くの家庭にいまだにインターネット用端末などとして残り続けている。 一方岡田は東大オタキングゼミで、98年当時の時点で任天堂が莫大な現金資産（たしか数千億円ほど）を持っていることに注目しています。 一般の大企業は、現金ではなく株券や不動産などの形で資産を蓄えています。しかし任天堂は、銀行口座の現金だけで数千億円という、非常に資金力の高い企業でした。今や日本を代表する世界的なゲーム大企業になっています。 また、日本だけでなくマイクロソフトのXBOXなど、実際に欧米の企業も昔はコンピュータゲームが産業の牽引役だと思って、先をこぞってゲーム機に参入していたわけでもある。岡田の未来予想は、決して根拠の無いものではなかったのです。 }} {{コラム|読書について| ゲーム業界と関連のない文献も、この教科書では出典として書かれていますが、これはこの頁の主要執筆者Sが、多量の市販本を読む以外に知的活動の方法を知らないことと、自分自身の文章の権威と信頼性を、著名人の威を借りて確立したいからでしょう。 ゲーム業界を志望するなら、ゲーム業界人の書いた本は少なくとも何冊かは読んでおくといいでしょう。 ネット上では、業界人ではないのにもっともらしく書かれた文章も多いですし、おそらく本Wikiの執筆者にも本格的なゲーム業界関係者は一人もいないでしょう。 業界人達のSNS発言ではなく、現代では書籍があるので、実際に書籍を手に入れて読むのがいいですね。書店で販売される書籍というのは、けっして著者だけの意見でなく、編集者や校正者、周辺の職業人達が査読をして、内容の信憑性を確認しています。 <!-- ニュース解説者の池上彰（いけがみ あきら）が、たしか2011年くらいのテレビ番組で言っていたことだと、編集者Sは言っている。 --> 何十冊も本を読むよりはプログラミングを書く実践のほうが重要でしょう。 『ゲームデザイン プロフェッショナル』著者であるFGOクリエイターも、ゲーム開発の書籍は読んでおくべきだと忠告しています<ref>『ゲームデザイン プロフェッショナル』、P234</ref>。また、ゲームデザイン本で学んだ知識は、ゲーム業界以外でも仕事術として活用できます。たとえば上司への業務報告の報告・連絡・相談（ホウ・レン・ソウ）などの考え方は、ゲーム業界でなくても活用できます<ref>『ゲームデザイン プロフェッショナル』、P332</ref>。 いっぽう、もし最新IT技術を勉強したいなら、読むべきは、ゲーム制作の解説本ではなく、そのIT技術の解説本など、そのものの書籍を読むほうが近道でしょう。 }} ===ゲームプログラミングは面白い。しかし、そんな楽な事ではない。=== ここでいう「プログラミング」とは、C言語などのプログラム言語による開発のことです。RPGツクールなど開発ツールによるゲーム制作の話は原則していません（本書『ゲームプログラミング』はあくまでプログラミングのための教科書です）。 さて、よくネットや、あるいは日常でも（C言語などによる）「ゲームプログラミングは簡単だよ。イラストやシナリオのほうが難しい。」、などという人がいますが、この発言の心は、「俺はプログラミングもイラストもシナリオも出来る凄い男だぜ。しかもプログラミングなんて簡単だし、むしろクリエイティブなイラストやシナリオの方に精力を費やす偉い奴だぜ^^」という、世間に良くいる武勇伝、自慢を語りたがる、インチキ親父が吹かしているだけなので、あまり真面目に取り合わないのが正解だと思います。 まず第一に、不当にプログラミングの価値を貶めている言説ですよね。 Visual C++またはVC# 、あるいは Direct Xなどを使ってプログラミングすることは、そんなに簡単なことではないでしょう。 ゲームプログラミングの入門書などには、初心者でも理解できそうな比較的簡単ないくつかのサンプルコードがありますが、それは初心者でも簡単に書けそうな技術だけを抜粋してるという、あくまで例外です。 RPGならたとえば、ドラクエ3のような戦争画面の行動順を処理するソート機能をつくるだけでも一苦労ですし、ほかにも道具・アイテムなどの自動整理をはじめとする標準機能を作るだけでも一苦労です。 決して上手い人のサンプルコードをコピーアンドペーストをして終わりという訳にはいかず（そもそも現状そのようなサンプルコードがネット上に無いですが）、もし仮にサンプルコードがネットに公開されていても、自作品に組み込む際にさらにそれをデバッグ（決してテストプレイの意味ではなく、実際にコード修正が必要になります）しなければならず、プログラミング言語の理解が必要です。 ゲームのプログラミングは決して楽ではないし、仮にもし楽だとしたら、じゃあゲーム会社のプログラマー職の人の仕事は何なんだ・・・という疑問につながりますよね（デマを言ってる人は、この疑問を脳内に都合よく無視しますが）。 ツクールやエディタのような制作ツールを使えば、C言語的なプログラミングは不要ですが、それはそのツクールなどのツールを開発している人達にプログラミングを肩代わりしてもらっているだけなので、決して「ゲームプログラミングが楽」、ではないでしょう。楽だというなら、じゃあツクール開発元の角川書店およびその発注先ソフトメーカーのプログラミングが楽だとでも言うのか・・・（デマを言ってる人はこの疑問を無視します）。 そもそもコンピューターゲームというのはプログラミングがなければ成立しないのですから、そのプログラミングの価値を貶めて平気な人は、コンピューターゲームにかかわる資格はないでしょう。 == ゲーム制作に関する留意点 == === IT的な留意点 === ====プログラミングなしでも同人ゲームを作れる==== 自分でゲームを作る際、必ずしも、C言語などプログラム言語で記述する必要はありません。 プログラミングをせずに、ほぼマウス操作と会話メッセージなどの文章のキーボード入力だけでゲーム開発をできるようにするソフトウェアが、有料または無料で発表されています。 たとえば、RPGを作りたいなら、日本で発表されているソフトでは、『[[w:RPGツクール]]』や『[[w:WOLF RPGエディター]]』などのように、RPG製作に特化された開発ソフトがあり、大幅に開発の手間を減らせます。なお、『RPGツクール』は有料製品です。『WOLF RPGエディター』は無料ソフトです。 アクションゲームを作りたいなら、『[[w:アクションゲームツクール]]』があります。これらツクール製品は有料製品です。（なお、かつて『[[w: 2D格闘ツクール2nd.]]』というのがありましたが、しかし現在ではサポート切れのため、今現在の市販の十字キーコントローラーが初期設定では動かない、一部のボタンしか使えないなど問題点があります。） また、ノベルゲームを作りたいなら、フリーソフトの『[[w:吉里吉里Z]]』などがあります。吉里吉里Zはソースコードが公開されており、オープンソースになっています。 :なお、とりあえず「ゲーム開発ツール」と呼びましたが、じつは呼び方は特に決まってはいません。「ゲーム制作ツール」と呼ぶ場合もあります。ゲーム開発ツールのことを「ゲームエンジン」と言う場合もありますが、開発ツール以外のゲーム用ランタイムのことも「ゲームエンジン」という場合があります。 :本Wikibooksでは、とりあえず、ツクールや吉里吉里シリーズやウディタ（WOLF RPGエディター）などのソフトの呼び方は、まとめて「ゲーム開発ツール」または「ゲーム開発ソフト」と呼ぶことにします。 C言語などによるプログラムは、上記のゲーム開発ツールを使わない場合の選択肢になるでしょう。 既存のゲーム開発ツールの仕様に不満を感じる場合に、「じゃあ自分でプログラムして作ろう」となり、プログラミングが必要になるわけです。 なお、上記の開発ツールはほとんどがWindows用のソフトです。MacやLinuxでは動きません。MacやLinuxで動作するゲームを作りたい場合は、別のソフトウエアを使う必要があります。 既存のゲーム開発ソフトを使わずにプログラムを組んでゲームを自作する場合、必ずしも既存のツールのような、ゲーム作品と開発ツールが分離された仕組みを再現する必要はありません。 一般的に初心者が、ゲーム開発ツールを作ることはほぼ不可能です。初心者は開発ツールを作ることは考えずに、まず1本、とりあえずゲーム自体を完成させてみましょう。開発ツールを自作したいのなら、まず先にゲーム1本を完成させたあとに、あとから開発ツールとゲーム作品の分離などに取り掛かるのが推奨です。 ==== 商業ゲームの開発言語 ==== 基本的に、現代の商業ゲームは、C言語で開発をする。 ただし、ファミコンの古いゲームは、アセンブラで開発されていた。ファミリーコンピューターからスーパーファミコンに至るまで、OSは搭載されていない<ref name="m289" />。 ではいつからC言語がゲーム開発に使われるようになったかというと、商学の学説では、プレイステーション（※ おそらくプレステ1？）の頃からだろう、と考えられている<ref name="m289" />。ただしこの時代でも、処理速度の高速化のためにアセンブラにアクセスする開発チームも少なくなかった<ref name="m289" />。 また、プレイステーションのOSは独自仕様である<ref name="m289" />。 カプコンなど一部の企業は、OSによる開発ではなく、移植性を高めるために自社製の内製フレームワークを用いて開発する。カプコンの場合、2010年頃は「MTフレームワーク」という自社製フレームワークを用いて開発を行っていた<ref name="m289" />。 {{コラム|ゲーム用のメーカー独自プログラミング言語について| ゲーム開発ソフトには、ゲーム開発用の独自のプログラミング言語を持っている場合があります。このような機能の実現方法は、原理的には、ファイル入出力の関数を使い、テキストファイルの文字列を読み取って、文ごとにプログラム動作を設定・実行している、と、考えられます。インタプリタは、このような方法で作られています。 ゲーム製作ソフトでの独自のプログラミング言語はたいてい、コンパイル作業を必要としないので、おそらくインタプリタ方式でしょう。 基本的にWindowsの場合、実行ファイルに変換するには、Visual Studio というマイクロソフト社の配布している開発環境が必要です。 Visual Studio が開発環境を提供していない独自言語は、たいてい、インタプリタ方式となると思われます。 コンパイラ方式に比べて、インタプリタは処理速度が不利なので、適用できるジャンルや用途が限られます。たとえば3Dアクションゲームには、インタプリタ方式は不向きでしょう。 これらの独自言語を使うにしても、自分自身で独自言語を作りたいと思うとしても、この教本ではまず、既存のプログラミング言語を使ってゲーム制作を開始することを推奨します。 }} ====ゲームのプログラム言語の歴史==== ゲームを書くために利用される言語は多岐にわたっています。歴史的にはゲーム業界でも、[[C言語]]や、特に計算機のスピードが重要になる場面では[[w:アセンブリ言語|アセンブラ]]を利用してプログラミングを行うことが普通に行われていました。<!-- (文献)→-->そのため、ゲームプログラミングは通常のプログラミングと違った技能が必要であるように思われていました。 現在では計算機がある程度速くなったことや、ゲームプログラムの開発を複数人で行うことでテクニカルなプログラミングが避けられるようになったことにより、ゲームプログラミングは他の一般のプログラミングと同じような課題だと見なされています。 しかし、特にアクションゲームなどのリアルタイムでの画面書き換えが必要なゲームで、プログラムのスピードが重視されることは変わっていません。また、コンピュータの性能があがるにつれ、それらの性能を全て引き出すように表現手段が変化してきたため（[[w:3次元コンピュータグラフィックス|3D]]、[[w:ポリゴン|ポリゴン]]などを参照）、状況によっては複雑で特殊なプログラミングが必要になることもあります。 ===== 初心者が使えるプログラミング言語 ===== ゲーム開発において、一般にゲームショップなどで流通している商業ゲーム作品において、現在よく利用されているプログラミング言語として、[[C言語]]、[[CPlusPlus|C++]]、[[Java]]があげられます。 Windowsの3DエンジンのDirectXは、主にC++を想定しています。なので負荷の高いアクションゲームを作りたい場合、Visual C++での開発が安全でしょう。 しかし、ネット上のフリーゲームでは、C++以外の言語が使われることも、よくあります。 さいきんゲームエンジンとして有名なUnityは、言語としてはC#の文法を採用しています。 [[w:携帯電話|携帯電話]]向けのゲームでは[[Java]]が利用されましたが、これは携帯電話を提供する各社がJavaをアプリケーションの言語として選んだことによります（[[w:iアプリ|iアプリ]]、[[w:EZアプリ (Java)|EZアプリ]]、[[w:S!アプリ|S!アプリ]]などを参照）。現在でもAndroidなどのスマートフォン向けでは、Javaが使われています。 市販の書籍では、Pythonによるゲーム開発を紹介した出版物もあります。ただし Python は原理的にインタプリタ方式であるために処理速度がC++に劣り、アクションゲームなど負荷の高いゲームを作る事を目指している場合は、将来的にはPythonからC++への装備変更が必要になるかもしれません。 ===== ゲームに適さない（だろう）言語 ===== ;Flash関係 例えば、かつて Adobe の Flash が、ブラウザで動かせるゲームを作る際に、よく使われていました。このようなwebブラウザ上で動くゲームのことを一般に、「ブラウザゲーム」と言います。ただし、現在ではFlashは廃止の方向です、すでにほぼ廃止されているといっていいでしょう。また、現状では、ローカルPC環境でのゲームをJavaScriptで作るのは、アマチュア段階では困難です。JavaScriptのアマチュアゲームと言う事例を聞きません。 ;JavaScript なお、JavaScript はクロスプラットフォームですが、しかし、セキュリティ上の理由などから、いくつかの機能（たとえばファイル入出力）がwebブラウザ上では使えないようになっており、そのため、JavaScript だけでゲームを作るのは、初歩的なゲームを除くと、かなり困難です。（おそらく、オンラインゲームでは、サーバー側でPHPやサーバサイドJavaScriptなどの別プログラムが走っていると思われます。） セーブ機能の必要なゲームを作る場合は、JavaScriptでの開発は選択肢にない（セーブの実装には、JavaScript国際規格にはない非標準仕様を使いこなす必要があり、かなりの技術力を要するでしょう）。 =====ブラウザゲームの初歩的な原理===== 商品として流通するようなゲームや、高度な機能を持つブラウザゲームを作ることはとても難しく、このページでは手に負えません。そこで、このページでは、初心者が練習用につくるゲームを例に記述します。 webブラウザだけで動くのがブラウザゲームです。ブラウザゲームを作るのに使う言語の第一選択肢はJavaScriptです。サーバー側の処理が必要ならPHP,Python,Perl,Javaなどの言語の出番でしょう。 「ネットワークゲーム」は「ブラウザゲーム」とは意味が違います。 「ブラウザゲーム」は、パソコンにwebブラウザさえあれば、ネットワークに接続していなくてもゲームプレイできて、最後、クリアまでプレイできる作品もあります。 しかしネットゲームは、ネットワークに接続しないと、ゲームを開始することさえ不可能です。つまり、サーバの提供するゲームが「ネットワークゲーム」「ネトゲ」です。 もしPHPやPerlなどでゲームを作る場合、普通はネットゲームになる筈なので、作者がサーバを構築して提供する必要がありますし、プレイヤーにはゲーム中にサーバに接続する環境が必要になります。提供者は、サーバを用意したり、保守管理する必要がありますよね。サーバーがダウンしてしまうと、プレイヤーがゲームをできなくなります。 「PHP ゲーム」などの単語でネット検索したり、あるいは書店でプログラム言語の書籍や解説サイトを見ると、ときどきPHP・Perlなどの言語でゲーム開発しているものもありますが、一般的なダウンロード型のゲームとは違う筈なので、気をつけてください。 {{コラム|ソケット通信、ほか| コンピュータプログラムからインターネットに通信するには、いくつかの方法がある。 C言語の場合はOSの提供するソケット通信といわれる機能を使う方法、 JavaScriptにあるHTTP通信の機能を使う方法、 などがあるだろう。 ただし、JavaScriptでゲームを制作するのは、セキュリティ上の制約などからセーブロードが標準的方法では困難など、とても制作が難しい。 よって本セクションでは、C言語にソケット通信を組み込むことの概要を説明する。 ゲーム制作初心者がソケット通信までする必要はないが、将来的には知る必要があるかもしれない。 本wikiではWindowsの場合については 教科書『[[WinSock]]』、 macやLinux / Unix や BSD の場合は 教科書『[[Unixソケットプログラミング]]』 で説明している。 Windowsとそれ以外のOSとで、ソケット通信の仕様が微妙に異なる。 ソケット通信では文字コードの問題がある。手元のパソコンの文字コード設定は、通信相手方の端末には反映されない。 Windowsの日本語版では、伝統的に Shift-JIS といわれる文字コードが使われてきたが、海外のWindows端末は日本の文字コードにあわせてくれないし、macやLinuxやBSDも同様に日本には合わせてくれない。 簡単な対処法として、ゲーム中では日本語を送受信しない、つまり半角の英数字と記号だけを送受信する、という道はある。 会員登録などのためにどうしても氏名や住所などの日本語を使う必要がある場合、PHP・Pythonなどサーバ言語に対応した「フレームワーク」があり、そのフレームワークが最初から日本語に対応、もしくは設定を少しいじるだけで日本語対応するので、それを利用すれば効率的かもしれない。 ゲームとは別途、サーバー側にフレームワークをインストールして、会員登録時にサーバー側でそれを使うようにすればいいだろう。 しかしゲーム内では日本語の扱いは非常に難しい、限定されるという事になるだろう。 C言語のプログラムにサーバサイドの言語・システムを組み込むのは難しいから、ネットゲームではどこかでソケット通信に頼ることになるだろう。 市販の本を探しても、そもそもソケット通信の書籍自体がめったに見当たらないし（ほんの少しだけ出版されている）、もし見つけても全く文字コードの問題の解決方法は紹介されていない（2021年現在）。 }} ====プラットフォ－ム==== ;ライセンス料 一般に、プレイステーションや任天堂のゲームを開発するには、専用の機材が必要であり、そのため、ソニーや任天堂とライセンス契約しなければいけない<ref>『ゲームプランとデザインの教科書』、P.107 </ref>。 その契約に際して、ライセンス費用または料金と呼ばれるものを、ゲーム機開発会社の任天堂、ソニーに支払う必要があります。 現在でもソニーや任天堂のゲーム機用のソフト開発・販売には、ライセンス料が必要です。少なくともPS4やニンテンドースイッチのパッケージソフト開発には、「ライセンス費」が必要<ref>川上大典 ほか著『ゲームプランとデザインの教科書』、秀和システム、2018年11月1日第1版第1刷、P.120</ref>。 なお、書籍『ゲームプランナーの新しい教科書』によると任天堂やソニーのようにゲーム機を作っている会社のことをハードメーカーと言います。つまり、ゲーム機のハードメーカーにライセンス料を支払うという仕組みになっています<ref>『ゲームプランナーの新しい教科書』、P20</ref>。 また、スマートフォン向けアプリは、プラットフォーム使用料が掛かります。 書籍『ゲームプランとデザインの教科書』によると AppleStore, GooglePlayともに売上げの30%とのこと<ref>川上大典 ほか著『ゲームプランとデザインの教科書』、秀和システム、2018年11月1日第1版第1刷、P.121</ref>。その他のプラットフォームも、大体同じとのことです（参考文献の著作の時点では）。 Google やAppleのようにプラットフォームを提供している企業のことをプラットフォーマーと言います<ref name="gp244">吉冨賢介『ゲームプランナー入門』、P244</ref>。 昔からゲーム機のライセンス料は有料で高額であり、ソニーや任天堂の収益源のひとつになっている<ref>青島矢一ほか『メイド・イン・ジャパンは終わるのか』、東洋経済、2010年8月12日発行、P.267 </ref>。一方、パソコンゲームにはライセンス料が無いのが普通です<ref>青島矢一ほか『メイド・イン・ジャパンは終わるのか』、東洋経済、2010年8月12日発行、P.283 </ref>。 なお、ハードメーカーでなければプラットフォーマーでもないゲーム会社のうち、製造から販売までを手がける会社のことをパブリッシャーといい、たとえばカプコンやコナミやセガやスクウェア・エニックスやバンダイナムコなどがパブリッシャーです<ref name="gp244" />。 実は、必ずしもパブリッシャーが開発を手がけるとは限らず、スマホ向けアプリなどではディベロッパーといわれる開発専門の会社に委託している場合もあります<ref>吉冨賢介『ゲームプランナー入門』、P245</ref>。 ;ポリコレ規制 Apple社のAppStore向けのスマートフォンアプリでは、アップロード後に、公開前にAppleによる審査があり<ref name="g139">川上大典ほか著『ゲームプランとデザインの教科書』、秀和システム、2018年11月1日第1版第1刷、P.139</ref>。、審査は欧米基準です。 GooglePlayは、公開前の審査はないが公開開始後に海外基準で審査されるので、それに違反していると配信停止になります<ref name="g139" />。 海外プラットフォームで販売・配布したい場合、「ポリティカル・コレクトネス」（政治的な正しさ）といわれる、海外の公序良俗の基準に配慮する必要があります<ref>『ゲーム作りの発想法と企画書のつくりかた』、P.235</ref>。 欧米の判断基準が、アジア諸国やアフリカの生活習俗に合致しない場合も多いのですが、欧米のIT大企業はその欧米基準での規制が政治的に正しいと考えているでしょう。「日本では、少し考え方が違う」と言っても、通用せず規制される場合も多い。 ゲームだけでなくテレビアニメでも、漫画ワンピースの海外アニメ版では、主人公側の若者がタバコを吸っているシーンをアメ玉に作画を変えられたり、ドラゴンボールに出てくるミスターポポという肌の真っ黒なキャラクターの肌を青く書き換えたり、色々な例があります。 ポリコレとは関係ない事例ですが、TVアニメーションのポケットモンスターで主人公のサトシ達がお握りを食べているシーンで、アメリカ版ではドーナツになっていたことがあります。これは、国による食文化の違いを示していますよね。 ===プロトタイプ=== ゲームでは、曲や絵が良くても、ゲームとしては今ひとつ面白くない、という事は起こり得ますよね。 ですからむしろ、商業的なゲーム制作では、イラストは簡略なものを使ったうえで、プログラム中心の試作品（プロトタイプ）をいくつか作り、その中でゲームとしての面白さがあるものを、取捨選択したうえで商品化を考え、その後イラストや楽曲を詰めて完成度を高めていく、と、いう制作過程を取るようです。 書籍『ゲームプランナー入門』（吉冨賢介 著）によると、商業ゲーム界では、企画書に書かれたゲームが本当に面白いかどうか確認するために、「プロトタイプ」が作られます。プロトタイプの段階では、プログラマーと、企画の意図を考慮するためプランナーも関わります。<ref name="gp17">吉冨賢介『ゲームプランナー入門』、P17</ref> イラストレーターは、プロトタイプの前段階あたりでイメージイラストを提供し、スタッフ間の共有イメージを作ります<ref name="gp18">吉冨賢介『ゲームプランナー入門』、P18</ref>。そしてプロトタイプ進行中は、グラフィック案の提案をしていきます<ref name="gcw56">蛭田健司『ゲームクリエイターの仕事 イマドキのゲーム制作現場を大解剖』、翔泳社、2016年4月14日初版第1刷発行、P56</ref>。サウンドも同様、プロトタイプでは、曲調を固めていく段階です<ref name="gcw56" />。 :※時々あるトラブルとして、マイナーな同人ゲームや零細メーカーのゲームで、背景イラストや脇役キャラクターなど目立たない部分で他社のイラストが使われていることがあるようです。おそらく試作用に流用したイラストが、そのまま製品に混入したのでしょう。こういうトラブルがあるので、他社イラストの使用は試作であっても避けるべきです。 ;実装検証 プログラマーは、そのゲームでコアになるプログラムやシステムやミドルウェアについて、プロトタイプ段階で実装検証を済ませておく必要があります。プロトタイプより前の原案の段階では、利用するミドルウェアの洗い出しをして、出来る範囲での基礎実験をしておきます<ref>蛭田健司『ゲームクリエイターの仕事 イマドキのゲーム制作現場を大解剖』、翔泳社、2016年4月14日初版第1刷発行、P54</ref>。 ミドルウェアによっては使用料が発生するので、その点を事前に調べておく<ref>蛭田健司『ゲームクリエイターの仕事 イマドキのゲーム制作現場を大解剖』、翔泳社、2016年4月14日初版第1刷発行、P55</ref>。 プロトタイプのうち、張りぼての例えば画面だけの物等を、「モックアップ」といいます。一方である程度遊べる状態まで作っているものを、「プレアブル」といいます<ref>STUDIO SHIN『ゲームプランナーの新しい教科書』、翔泳社、2018年3月10日初版第2刷、P251の図</ref>。 ゲームデザイン本ではよく「プロトタイプ」という表現が用いられるので、本ページではこの言葉を使うことにします。 {{コラム|商標権等| 知的財産権には著作権・商標権・意匠権などがありますが、商標権は特に強い権利であり、気を配る必要があります。 意匠権とは、建物や工業製品の外観に関する権利なので、ゲーム制作ではあまり気にする必要はないようです<ref name="gpd135">川上大典 ほか著『ゲームプランとデザインの教科書』、秀和システム、2018年11月1日第1版第1刷、P.135</ref>。 「特許権・実用新案権」と「商標権」は、事業者によって国に登録されている権利で、かなり強力な権利なので、気をつける必要があります。 特許権や実用新案権とは、大まかに言えば、技術的な発明に関する権利です。商標が登録されているかどうかは、特許庁の『特許情報プラットフォーム』というwebサイト<ref name="gpd134">川上大典 ほか著『ゲームプランとデザインの教科書』、秀和システム、2018年11月1日第1版第1刷、P.134</ref>で確認できます。 商標をトリッキーな意図で登録する人も多く、自社でビジネス展開をする気がなかったり、他社の商品などでまだ登録されていない物を申請したり、そういうやや不正な登録申請でも認可されてしまう場合も多いです。 また、商標は業種のジャンルごとに分かれているので、たとえば携帯電話のジャンルが新たに追加された時代に、過去のゲームの商標を登録した人がいました。そのため携帯ゲームを出せなかったり、商標を買い戻したり、取り戻すための裁判をするのに時間とお金がかかってしまったり、様々な問題が発生します。<ref name="gpd134" /> 著作権は、登録の必要がなく、著作をした時点で発生する権利です。 『ゲームプランとデザインの教科書』によると、こういう事柄にまだ慣れていない人によくあることなのですが、他人の個人サイトやSNSで公開されていた絵や曲などを、許可なく勝手に使う事例があるようです<ref name="gpd135" />。 二次利用を許可されてない著作物は素材として使えません。 そして見落としがちなのが、フォントの著作権です<ref name="gpd135" />。フォントにも著作権があります。 フリー素材と書かれていても、商用販売が禁止されている配布形態のものもありますので、気をつけましょう。 }} {{コラム|アイデアの権利。アイデアとは盗まれるのか、盗むのか?| 商業ゲーム作家たちの、2022/1時点でのSNS発言によると、業界全体でみられることですが、会社外部の人がアイデアを一方的に投稿してきて、会社で作った作品にそのアイデアと類似点があったら、アイデア使用料を要求してくる、そのような問題に悩まされているようです。 そこでゲーム会社側では原則、 :送られてきたハガキやメールは、まずクリエイター以外の事務系の人間が読む。 :もしハガキなどにアイデアがあった場合、そのハガキを処分。 などの方策を取ると言われています。 また、偶然や何らかの理由でアイデアが一致してしまった場合に備えてのリスク回避として、事前に会社のウェブサイトなどで「弊社にアイデアが送られてきた場合、そのアイデアは弊社のものになります」のような宣言をしている会社も多くあると言われています。<!-- （以上、作家のSNS発言やそれを紹介したサイトの取材などのまとめ.）←出典を消すなってS氏はやたら云うんだけど，そんな重要な事かね?もちろん全くなくて，いい加減な事書いていいと言ってるわけではないけど… --> ここで前編集者は娯楽産業の世界には厄介な消費者がいると言及しているけど、この前編集者自身がこのWikibooks で異常なまでに厄介な参加者なんだが、そろそろ人のふり見て自分を返り見るべきだと思うな。 法学的には、著作権法はアイデアを保護しません（『アイデア・表現の二分論』と言います）。 そして前編集者はアイデアに関して権利をどうこう言う人間を無知だと書いているけど、自分は至上の賢人だと思ってるようだね。 そしてこの人物は他者を愚弄する時は必ず自分の意見ではなく、権威ある人がそう書いたから、出典だからと宣う。 出典は岡田斗司夫氏の著作『東大オタク学講座』や『マジメな話』だそうだ。 まあ岡田氏ならかなり過激なことを書くのは事実だろうが，この前編集者S はその悪徳をさらに10倍に高めてこのWikibooks に記述する地獄のように厄介で無知で馬鹿な人間だ。 }} 任天堂『ゼルダの伝説 ブレス オブ ザ ワイルド』は、プロトタイプの段階ではイラストや音楽を組み込まずに（イラストは、代わりに大きなドットの塊などで代用する）作られている事がゲーム業界見本市イベント CEDEC 2017 で公開されています<ref>https://game.watch.impress.co.jp/docs/news/1078888.html 2020年11月25日に閲覧して確認</ref>。 プロトタイプの段階では、画像や音楽は発注せず、骨組み的なプログラムだけで、そのゲームのアイデアが「はたして本当に面白いか？」を、実際に社内の関係者にプレイさせてみて確認します。 因みにプロトタイプに関しては『[[高等学校情報/その他の技術的な話題#プロトタイプ開発]]』の記述も参考になる。 ここでいう「プロトタイプ」（試作品）とは、コンピュータプログラムのゲームとして動作するのが前提です。映画製作でいう絵コンテ試写のように、ゲームの試作では、なるべく早期に第三者が試作ゲームを遊べるように作っていく必要があります。 プロトタイプという言葉を使用すること自体が妥当かどうか。まず、書籍『ゲームプランとデザインの教科書』で使われている<ref name="gpd350">川上大典ほか著『ゲームプランとデザインの教科書』、秀和システム、2018年11月1日第1版第1刷、P.350</ref>。 ニコニコ動画の経営者、川上量生が使っています<ref>川村元気『理系に学ぶ』、ダイヤモンド社、2016年4月21日 第1刷発行、P.38</ref>。川上は角川書店も買収したので、おそらくそこ（カドカワ・RPGツクール販売元）でも使っているでしょう。 ゲームのプロトタイプの基本姿勢は、「汚く作って、やりなおす」です<ref name="gpd350" />。もちろん最低限のプログラムの知識、勉強は必要ですが、あまり知識収集や理解充実を気にするより、実際に作ってみることを優先したほうがいいようです。チーム制作をしている場合はプロタイプは赤ん坊であり、そのチームで育てていこう、我々の子供だという意識で接しているようです<ref name="gpd350" />。 勉強に関しては、汚くてもいいからまず工夫して作ってみると、何を勉強すればいいかが見えてきます。 英語では「quick and dirty prototype」という言葉があります<ref>川上大典ほか著『ゲームプランとデザインの教科書』、秀和システム、2018年11月1日第1版第1刷、P.349</ref>。 書籍『ゲーム作りの発想法と企画書のつくりかた』によると、シナリオライター志望者が企画書やシナリオ案をメーカーに送りつけても、あまり効果的ではないようです。 それよりゲーム形式でシナリオを書いてしまうのがいいようで、「CHR:ヒロインA(私服)、表示」のような文章を織り交ぜて構成していくのが推奨<ref>『ゲーム作りの発想法と企画書のつくりかた、P.140</ref>。 参考文献のその章では、シナリオライター志望者に向けて語られていますが、プログラマーを目指すならどうすればいいでしょうかね。 プログラマー志望なら、サンプルゲーム、サンプルプログラムを作ってしまうのがいいかもしれません。 1990年代、週刊少年マガジンに不定期掲載していた読みきり漫画『ゲームクリエイター列伝』では、カプコン社のゲーム『バイオハザード』を扱った『バイオハザードを創った男達』の際、制作過程でゲームデザイナーが大幅な作り直しを判断して進行させた、という描写があります。（ただしWikiboooks一編集者の記憶、詳細はあいまい）。 のちの、ゲーム評論家の阿部広樹の評によると、むしろそれは劇的な大きな決断ではなく、ゲームデザイナーの日常の普通の仕事ではないか、と語られています。 どんな肩書の人間だろうと、すでに決まって進行していた方針をひっくり返すのは、かなりのストレスのある判断で指摘になりますが、一般に漫画や映画、あるいはNHKの仕事に関するドキュメンタリーでもそうですが、職業や職業者の物語では、過剰に対象を美化し、劇的な演出によって関係者を称賛し、英雄視する傾向があるように思います。 {{コラム|アイデアはアイデアで価値がある。でも、せっかくなら、それを試作して、形にしてみよう。| ゲーム業界人広井王子は書籍のインタビューで、自分の社長としての人材評価は「0点」から始まる「加点法」だと語っていたようです。 『ゲームデザイン プロフェッショナル』著者も、文脈は違いますが「加点方式で物事を考える」と述べています<ref>『ゲームデザイン プロフェッショナル』、P224</ref>。 正直インチキなゲーム業界人の点数勘定などには全く興味ないが、そんな話とは全く別に、ゲーム制作の上で、実際に動く簡単なプロトタイプを作ってみることは間違いなく有意義な事でしょう。 アイデアはアイデアとして、思考や思想の展開としてありますが、それを具体的な形にしてみることは非常に楽しくエキサイティングで、意味ある活動ですよね。 }} 仕様書や設定資料を超えて、誰もが遊べる試作品は、意味のある企画行為でしょう。前編集者は、時間軸・動きの制作意図の明確化、という言葉を使っています。もちろん短くまとめること自体もなかなか難しいのですが、工夫を凝らして、ゲームプログラムを完成させることが重要な経験であり、思考の具体化でもあると思います。 ===アルファ版=== アルファ版はプロトタイプとは違うもので、その後段階で、ゲームの全体像が分かる一部分を、商品に準じた形で作ることです<ref name="gp17" />。 アルファ版でもそのゲームが本当に面白いかどうか検証がなされます。サウンドやビジュアルは商品に近いほぼ完成化された形で取り込みます。 アルファ版の使用の結果、プロジェクト中止の決定がなされる場合もあります<ref name="gp18" />。 ベータ版とは、会社によって意味が多少違いますが（たとえば『ゲームデザインプロフェッショナル』と『ゲームプランナ－入門』とでも微妙に違う）、おおむね、とりあえずのゲーム、最初からエンディングまでのほぼ完成状態をひととおり遊べる制作物です<ref>『ゲームデザインプロフェッショナル』、P170</ref>。 細かいバグ修正はこれらの段階では後回しにします。 基本的に :プロトタイプ→アルファ版→ベータ版→調整→デバッグ の流れですね。 ===プロトタイプ制作に必要な予備知識=== ====数学は後回し==== ゲーム制作の作り始めにおいて、必要な数学や物理の予備知識は、それほど多くありません。 文献『ゲームクリエイターの仕事 イマドキのゲーム制作現場を大解剖』によれば、数学や物理の習熟に拘って、それに多くの時間と精力を費やして勉強するよりは、3Dの勉強などで必要を感じたら、そのつど、その分野の数学や物理を学ぶのが効率的だと述べており、また可能なら実際にプログラミングでその理論を試してみると具体的に理解をしやすいと述べています<ref>蛭田健司『ゲームクリエイターの仕事 イマドキのゲーム制作現場を大解剖』、翔泳社、2016年4月14日初版第1刷発行、P88</ref>。 ====C言語の予備知識は入門書1冊+αで十分==== C言語を使ったゲームは、予備知識はそれほど多くないので、あまり難しいことは考えず、まず実際にプログラムを書いて作ってしまう事優先にするのが正解なようです。 市販のC言語入門書で、配列や関数などの一般的な機能を一通り習得したら、あとはVisual C++ で映像出力とキーボ－ド入力のみを、1～2週間ほど勉強、そしてVisual Studioを起動してゲームを作り始める。 うまくいけば数か月以内に、パソコン用の非ネット通信のゲームを作ることができるでしょう。 ただ、ゲームプログラミングを試みる人は、必ずしもゲーム制作のみが絶対的な唯一の目標ではない可能性もあるので、それぞれの立場に応じて、座学を取り入れてみるのもいいと思います。 == 作業リストを作る == ===作業リストの制作開始の方法=== さて、ゲームを作る時は、アイデアを頭の中だけに置いておくのではなく、文章に書きだしてみましょう。 そして、壮大な長大なアイデアではなく、1週間～1ヶ月ていどで成果の確認できそうなアイデアだけを書いてみましょう。 次にそのアイデアを、実際に動作するプログラム、ソフトウェア（つまりプロトタイプ）にするために、具体的などんな機能を持ったプログラム（簡単なものでよい）を制作しなければいけないか、自分のやるべきことのリストを、箇条書きで作ります。<ref>https://www.youtube.com/watch?v=J5FCZG7dfEY 2020年3月17日に閲覧</ref> IT界ではこういうリストを「ToDoリスト」（読み: トゥードゥーリスト）とか「タスクリスト」といいます。このページではむしろ日本語で、「作業リスト」と呼んでみましょう。 さて、このリストを作るときは、作業項目は具体的かつ単純な目標に分割します。ですから例えば RPG の戦闘システムを作るときは、 *「戦闘システムを作る。」 と、あいまいに総体的に書くのではなく、具体的に、 *戦闘画面のメッセージ表示欄および標準メッセージを作る。 *「戦う」コマンド選択欄を作る。（動作するコマンドはまだ「戦う」だけ。「逃げる」「魔法」などは後回し。） *主人公1人用の「戦う」コマンド用のダメージ計算システムを作る。 *主人公以外の味方キャラのぶんの表示欄も戦闘画面に追加する。 *味方キャラが素早さ順に行動する処理を作る。 という風に、作業項目を細かく分割していきます。 こうすることで、作業がひとつずつ比較的に簡単な要素に分解されていくので、楽になります。また、バージョン管理ソフトを使って管理している場合も、上記のような作業リストの分解をしておけば、各バージョンの概要を書く際にも作業リストの項目が転用できるので、一石二鳥です。 予定日は書かないほうがいいように思われます。スケジュールを管理したい場合は、別にファイルを作るといいですね。 そして書き出した項目を優先順位で並べたら、最初の作業リストは完成です。 ===作業リストの更新=== プログラミングする前に作業リストを眺めて、そして上の項目から実際に作業を開始しましょう。 そして一つの項目を完成させましょう。 そして作業項目がひとつ終わったら、「【完了！】」等、そういう情報を、項目の前または後ろにつけます。備忘のための記録ですね。 たとえば、 *【完了！】戦闘画面のメッセージ表示欄および標準メッセージを作る。 *【完了！】「闘う」コマンド選択欄を作る。（動作するコマンドはまだ「戦う」だけ。「逃げる」「魔法」などは音回し。） *主人公1人用の「戦う」コマンド用のダメージ計算システムを作る。 *主人公以外の味方キャラのぶんの表示欄も戦闘画面に追加する。 *味方キャラが素早さ順に行動する処理を作る。 こうします。 以前の記述を残したまま、その作業が終了したことを示しておくわけですね。 また、もし追加の作業が必要になったら、たとえばダメージ計算システムを作るために、ランダム計算が必要になって、自分がそのプログラム言語でのランダム計算に詳しくないなら、たとえば *【完了！】戦闘画面のメッセージ表示欄および標準メッセージを作る。 *【完了！】「闘う」コマンド選択欄を作る。（動作するコマンドはまだ「戦う」だけ。「逃げる」「魔法」などは音回し。） *Visual C++ でのランダム計算のとりあえず出来る方法について調べる。 *主人公1人用の「戦う」コマンド用のダメージ計算システムを作る。 *主人公以外の味方キャラのぶんの表示欄も戦闘画面に追加する。 *味方キャラが素早さ順に行動する処理を作る。 ::※3行目に追加されています。 と、必要に応じて項目を追加します。 さて、これから行う作業を検索しやすくするため、たとえば '''やることリスト''' *Visual C++ でのランダム計算のとりあえず出来る方法について調べる。 *主人公1人用の「戦う」コマンド用のダメージ計算システムを作る。 *主人公以外の味方キャラのぶんの表示欄も戦闘画面に追加する。 *味方キャラが素早さ順に行動する処理を作る。 '''完了した作業''' *【完了！】戦闘画面のメッセージ表示欄および標準メッセージを作る。 *【完了！】「闘う」コマンド選択欄を作る。（動作するコマンドはまだ「戦う」だけ。「逃げる」「魔法」などは音回し。） の様に完了した項目を後回しにしたり、或いは *【完了！】戦闘画面のメッセージ表示欄および標準メッセージを作る。 *【完了！】「闘う」コマンド選択欄を作る。（動作するコマンドはまだ「戦う」だけ。「逃げる」「魔法」などは音回し。） *（現在→） Visual C++ でのランダム計算のとりあえず出来る方法について調べる。 *主人公1人用の「戦う」コマンド用のダメージ計算システムを作る。 *主人公以外の味方キャラのぶんの表示欄も戦闘画面に追加する。 *味方キャラが素早さ順に行動する処理を作る。 のように、（現在→）、を追加するのも良いでしょう。 つまり作業の記述をそのままに、どこまで進展しているかが分かる等に書き足していくわけですね。 ==プロトタイプ制作における創作面の検討事項== ===ゲーム性=== 「ゲーム性」という概念があって、これがあるからこそゲームは面白く、魅力的だと考えられています。 プレイステーション開発元のソニーもこれを重視していますし、一般的に多くのゲーム愛好者、関係者たちもその考えに同意するでしょう。 ではゲーム性とは何か? ゲームのジャンルにもよりますが、「駆け引き」や「戦術」、これが「ゲーム性」だとよく言われます。 『ゲームプランとデザインの教科書』によると、ゲーム性とは、シューティングやアクションでは「対戦の駆け引き」、RPGでは「戦闘と物語の介入」、シミュレーションゲームなら「戦略性」だそうです<ref>『ゲームプランとデザインの教科書』、P152</ref>。 ただし上述の書籍によると、1990年代は今よりもゲーム性とシステムが重視されていたとの説明があるので、裏を返せば2010年以降の現代では、ゲーム業界ではゲーム性の重視の比率は1990年代よりも減っているかもしれません<ref>『ゲームプランとデザインの教科書』、P302</ref>。 『ゲームプランナー入門』（吉冨賢介 著）では、ゲーム性とは「課題や挑戦の仕組み」であると結論づけています<ref>吉冨賢介『ゲームプランナー入門』、P36</ref>。そして、この達成感こそが「ゲームならではの面白さ」だと述べています。 ;アクションパズルゲーム「I.Q」 メディアクリエイターの佐藤 雅彦氏（「だんご3兄弟」や「ピタゴラスイッチ」等を手掛けている）が、初めてかかわるコンピュータゲームで、ソニー・コンピュータ・エンターテインメントとの共同企画で、のちに「I.Q」（1997年にシリーズ第一弾を発売）と呼ばれるシリーズに携わった時、プロトタイプが全くゲーム性のないものになってしまい、それをプレイしたソニーの幹部陣の顔色が非常に曇ってしまったようです<ref name="br67">川村元気『理系に学ぶ』、ダイヤモンド社、2016年4月21日第1刷発行、P.67</ref>。 ここでの悪い反応、薄い反応の理由がわからなかった佐藤氏が、階段の踊り場でソニーの新人に尋ねてみると、「それが、あの、ゲーム性がないっていうか・・・」と言われたと出典の対談集に書かれています<ref name="br67" />。 基本的に佐藤氏は、プロトタイプの企画を提案しただけですが、ソニーにはプロトタイプを作るための部署があるらしく、1～2ヶ月かけてそこでプロトタイプが作られたようです。 この問題の責任が誰にあるかは、大した重要な事ではありませんが、商業作品としてプロトタイプを作る以上は、どこかの段階でゲーム性を意識して、プログラムに盛り込む工夫が必要になるでしょう。 ===ゲームの見た目とは？=== ふつうゲームのプレイヤーは、まず最初にそのゲームの「見た目」を判断し感受するでしょう。ですからその見た目のインパクト、興味を呼び起こす構成が必要になります。 例えばスーパーファミコンRPG『新桃太郎伝説』では、開発当初はドラゴンクエスト5 のようなマップ画面のトップビューUIでしたが、開発中にクォータービューの他社製RPGが発売されて高い評価を得たので、マップUIを（トップビューではなく）クォータービューに作り直したようです。このことは攻略本『新桃太郎伝説 究極本』に開発裏話として書かれています。 一方現在でもこの方向の試みは重要なようで、書籍『ゲームデザイン プロフェッショナル』の著者は、他企業の製品の画面と、自社の製品を目で見比べる分析方法で、自分たちの製品のUI の問題を見出しています<ref name="gdp199">『ゲームデザイン プロフェッショナル』、P199</ref>。 割と素朴で単純で即物的な見た目、「かっこいい」とか、「ぱっと見派手」等の要素が非常に重要なようです<ref name="gdp199" />。 商業としてゲームを作る以上は、ペイしなければ企業も事業の継続も維持できませんから、考慮せざるを得ない問題ではあります。 == ゲーム開発ツールを使う場合 == ====開発ツールのライセンス条件==== ゲーム開発ツールのなかには、そのツールで開発したゲームソフトに義務として「この開発ツールで開発したソフトウェアは、ソースコードを必ず公開しなければならない」などの条件をつけている場合があり、このような条件を「開示義務」（かいじ ぎむ）または「ソース開示義務」などといいます。 ソース開示が嫌な場合は、開示義務のあるツールは使わないのが正解ですね。 ゲームに限らず、ソース開示を義務としている開発ツールは多くあるので、ライセンスには気を配る必要があります。 「有料ソフトの販売を禁止」とか「アダルト作品の開発は禁止」などの条件をつけている場合も、ありえます。 ですからゲーム開発において、ツールのライセンス条件の確認は、非常に重要です。 {{コラム|GPLライセンス違反| GPL（ジーピーエル）というライセンスがあって、Linuxなどのオープンソースで使われています。このGPLを組み込んだプログラムは、ソースを公開しなければいけません。 ですから、ソース公開したくないプログラムには、GPLソフトウェアは組み込めません。 ゲーム業界でも、GPLライセンスのソフトウェアを組み込んでしまったために、呼出し元ソフトウェアでのソースコードの一部を公開することになったゲームがあります。2005年頃、『ToHeart2』という美少女ゲームが、xvidというGPLソフトを取り込んだ疑惑によって、GPL違反の疑いでソース公開になりました。（[[w:ToHeart2#GPL違反とソース公開]]） GPLでも、たとえばLinuxサーバ上でソース非公開のアプリを動かすように、GPLのソフトウェアを非公開ソフトとは独立した状態で使う場合は、ソース公開の必要はない、と、考えられています。（これが必要有りとなると、オンラインのプログラムやネットゲームは全てソース公開しなければならなくなり、非合理な結果になる。） 特定のプログラム自体に、GPLソフトウェアのコードを取り込んだ時、ソースコード公開が必要になります。 }} {{コラム|BSDライセンス他| オープンソースの中には、どのような利用法であっても、利用者にソース公開を求めないライセンスもあります。BSDライセンスとMITライセンスはソース非公開で利用できます。 ゲーム制作ツールの吉里吉里Zは、修正BSDライセンスで公開されています。 もしライセンスのことがよくわからない、またはライセンスの学習に時間をかけたくないなら、オープンソースのツールを使うなら、BSDライセンスを使うのが安全です。 }} [[w:DXライブラリ]]は、GPLでもBSDライセンスでもありません（DXライブラリ説明書「DxLib.txt」には、どこにも「GPL」とも「BSD」とも書いていない）。DXライブラリは単にソースコードが公開されていて、著作権者の「山田 巧」氏が著作権を保持しているオープンソースなライブラリです。 このように、ネット上でソース公開されているソフトウェアには、ライセンスの複雑な解釈を嫌ってか、「BSD」や「MIT」などのライセンス条件を名乗らないオープンソースソフトウェアもあります。 {{コラム|自作ソフトでソース開示| 昨今ではオープンソースやフリーソフトウエアの発展などの背景もあり、「自作ゲームのソースコードやソースファイルも開示しよう」と思うゲーム作者もいるかもしれません。 然しソースコードを開示していることが原因で、トラブルに巻き込まれる場合もあるかもしれません。自分の作ったゲームのコードが悪用され、トリッキーないたずらや嫌がらせ、誹謗中傷などを受ける可能性も全くないわけではありません。 そこでライセンスに、利用による損害に対する保証が無いことを明示するのは、ある程度有効でしょう。大抵の著名なフリーソフトウェアライセンスには、この条項があります。他者の悪意を完全に防ぎ失くすることは難しいのですが、ある程度の対策は見出されていますし、自身でも見出していく必要があるでしょう。 }} ====開発ツールを使用しないという事==== 下記の理由（機能制限および移植性の悪さ）の問題から、あまり大規模な作品は開発ツールでは作らないでおくのが安全です。 大規模な作品の場合、Visual C++ などでコードを書いて開発することを推奨します。 =====機能制限===== ゲーム開発ツールを使う場合、そのツールにもよりますが、「○○ができない」、つまり特定の目的を果たすための機能を持っていない場合があります。 Visual Basic や Visual C++ には普通にある関数でも、開発ツールには無い場合も多い。 また、もし、いったんはゲーム開発ツールを使って目的の機能を持ったシステムを作ったとして、さらなる機能をそのシステムに追加しようとするときに、大幅な作り直しが必要になる場合があります（拡張性の悪さ）。 システムがモジュール化されていても、そのモジュール部分では大きく改変する必要がある場合もあるでしょう。 ですからゲーム開発ツールによるゲーム制作では、あまり大作を作ろうとしないほうが安全です。開発ツールで作る作品は、比較的に小規模な作品に、とどめておくことを推奨します。 Windowsの場合、本来なら Visual C++ などを使って、プログラム文法のいろいろな事に留意しながらプログラムを書きますよね。開発ツールを使う場合、 Visual C++ のコードを書かずに、ほぼマウス操作だけでプログラムを作ろうとしているわけですから、何かしらの制限があります。拡張性の悪さは、プログラム文法などの学習の負担を減らすためのトレード・オフのようなものですね。 =====移植性の悪さ===== また、もうひとつの問題点として、C言語への移植性の悪さがあります。 ソースコードが公開されていない開発ツールの場合、異なる開発環境にゲームのソースファイルを移植するのは、ほぼ不可能です（仮に、開発ツールのランタイムを模倣できたとしても、著作権などの法的な懸念が生じる可能性あり）。 ゲーム開発ツールで作ったソースを、Visual C++のソースに置き換えるのは、簡単にはできないし、ほぼ全面的に新たに書くことになるでしょう。 ==イラストレーター、デザイナー== ゲーム制作、業界において、イラストや音楽を作る部署、人物は、まとめて、"アーティスト"と呼んでいるようです。 ゲーム界の場合デザイナーというのは、プランナーやディレクターのことであり、管理職的な設計者のことで、美術的なクリエイターではない。design という英語には、機械建築の設計という意味もあります。 映像関係、画像系のアーティストはグラフィッカーと呼ばれることもあります。ムービー担当者、特にゲーム界では3D-CGの制作者をアニメーターと呼ぶことが多いようです。アニメーション業界では主に、手描きの原画、動画マンをアニメーターと呼びますが、最近は3D-CGアニメーション映画も多いので、すこし状況が変わっているかもしれません。 ゲーム業界とアニメーション業界、各会社企業、過去と現在で、「原画」「仕上げ」「絵コンテ」等、一般的な作業に関する言葉が、それぞれの状況で微妙に違った意味で使われることも多いですね。 …ところで前編集者はわざわざこの項目を作ったうえで、色々な場所での言葉の意味の違いを、クドクドと自分勝手な分かりづらい説明で長々述べた後、「混同しないように気をつけましょう。」なんて馬鹿馬鹿しい言葉で締めているんだけど、この人物の意図はどこにあるのだろう? 例えばデザイナーというのは一般的に、造形作品、図案、意匠を考案する人のことを言うのだから、ゲーム界の外の人間が多少その業界内での意味を取り違えても、それほど致命的なミスでもないし、罵倒、愚弄されるいわれもなければ、好き放題にその相手を罵倒、愚弄していいわけでもない。間違えて使っている人を見たら、その都度やんわりと教えてあげればいいだけじゃあない? だいたいその世界に現実に身を置いたら、そこでの言葉の意味、使い方なんて自然に覚えるものだし…。 それを得意げにこれが違うあれが間違いといちいち理屈書いて、いい気になって威張っているこの人物は何者なのだろう? 現編集者が思うには、この人物は、学問、知識、知恵、科学とは何かという事を、根源的に取り違えている、のだろう。 ==操作性== 操作性について、親指と人差し指<!-- ←ここ，中指って書いてあったけど，こっちだよね? -->だけでボタンプッシュなどの操作ができるように作成するのが基本です。中指、小指、薬指はコントローラのホールドに使うぐらいです。人間工学的に、小指や薬指は力が弱いので、微妙な操作には向かないことが知られています<ref>川上大典ほか『ゲームプランとデザインの教科書』、秀和システム、2018年11月1日 第1版 第1刷、P.48</ref>。 一般的にゲームプログラミングでは、 # プレイヤーからの入力を扱うことができる。 # ゲームが提示する内容を表示することができる。 入力と出力、この2点が機能として必要になります。 プログラミング言語とプレイヤーからの入力については歴史的にも、あまり変化がありません。言語では主に[[C言語]]、[[C++]]が用いられる。[[w:携帯電話|携帯電話]]向けのゲームでは[[Java]]が利用されましたが、これは携帯電話を提供する各社がJavaをアプリケーションの言語として選んだことによります（[[w:iアプリ|iアプリ]]、[[w:EZアプリ (Java)|EZアプリ]]、[[w:S!アプリ|S!アプリ]]などを参照）。現在でもAndroidなどのスマートフォン向けでは、Javaが使われています。 パソコンゲームでは、プレイヤーからの入力には通常、キーボードかマウスを利用します。他に[[w:ジョイスティック|ジョイスティック]]や[[w:ゲームパッド|ゲームパッド]]が利用される場合もあります。家庭用ゲーム機では[[w:コントローラ|コントローラ]]が利用されることが多いのですが、[[w:ニンテンドーDS|ニンテンドーDS]]や[[w:Wii U|Wii U]]では[[w:タッチパネル|タッチパネル]]、[[w:Wii|Wii]]では複数の入力機器が提供されることが発表されています。各種入力機器をプログラムから扱う手法自体は、普遍性があり、入力機器ごとに大きく変化しない、と、考えられています。[[w:デバイスドライバ|デバイスドライバ]]、[[高等学校情報B]]には、プログラムから周辺機器を扱う方法について多少の記述があります。 画面表示のうち、3Dの表現は割合難しく、ある程度の数学（高校、あるいは場合によってはそれ以上）の理解が必要でしょう。2Dに関してはプログラムの面では、さほど難しい部分はありません。 ==処理速度の問題== 基本的にプログラミングでは、関数を使って、処理をコンパクトにまとめ、定数ではなく変数で柔軟性のある操作をすることが求められますが、ゲームの場合は、この構造のせいで処理速度が低下することがあります。 現在のCPUの性能、速さはかなり高くなってはいますが、プログラム処理は無限に煩雑化できますから、やはり高度な処理を短時間でなすことが求められます。特にゲームは、リアルタイムの反応のタイミングが非常に重要ですからね。数学の指数計算についての雑学で、「新聞紙を42回おりたたむと、月に届く距離になる」というものがあります。(新聞紙の厚さ)*2^42、ですね。もっとも新聞紙の物性から言って、ほぼ不可能な操作ですけど^^;;。コードの内容、組み合わせによっては、このように計算量が指数関数的に膨大になってしまい、処理速度が非常に遅くなってしまう場合があります。 ですが、このセクションで後述するように、関数を用いる場合の解決策（※概要:あとでdefineやinlineに置き換え）があるので、プログラミングの初期のほうは、とりあえずバグを未然防止するために関数を活用するべきでしょう。 1980年代頃のファミコンなど古い時代のゲームでは、ストレージ容量（ハードディスク容量のこと）が、ボトルネックでした。「容量不足でイベントをいくつか削りました」と、当時のRPGなどのゲーム作家が述べるのは、ストレージ容量の不足のことですね。ただ当時のファミコンはROMカセットでハードディスクは無いので、まさにストレージ容量という言葉が適切でしょう。 しかし2010年以降の現代では、ボトルネックになっている要因は、ストレージ容量不足よりも処理速度です。 ゲームプログラミングに要求されるコード特性は、科学計算ソフトウェアや金融プログラミングなどの手法とは異なります。情報工学・情報科学で適切とされる「構造化プログラミング」などの歴史的に発展してきたプログラミング・パラダイムの理念とは反するようなコード開発方針になる場合もあります。しかしゲームプログラミングに限らず、限定されたハードウェアで特定の結果を速く得るためには、様々なトリッキーな手管が必要になるでしょう。 ;ツクール等制作ツール RPGツクールの制作元のカドカワ（アスキー社→エンターブレイン社→カドカワ（かつての「角川書店」） ）では、PRGツクールでのアクションゲーム開発は推奨していません。アクションゲームの場合は、同じカドカワの「アクションゲームツクール」で制作するよう、薦めています。 アクションゲームとターン制RPG では要求される特性が大きく異なり、なかには、ほぼ対立しているような性質もあります。 ツクールやウディタでも、万能にあらゆることがスタマイズできるわけではなく、その制作ツールの特性に依存しますし、主に処理速度の低下しない部分についてユーザが創作できるようになっているでしょう。 多くのRPG制作ツールはマップ操作や戦闘画面の基本システムのルーチンそのものは、あまりカスタマイズできません。画像や音楽は挿入できますが、例えば戦闘プログラムなら、「コマンド」の命令文など一部の派生的な部分だけが独自に作れる程度でしょう。 ですから、ツクールでどうしてもアクションRPGを作りたい場合、基本システムの改造はかなり困難だろうし、別途、アクションRPGのような動作をするマップイベントを作成する・・・ぐらいでしょうね。 ツクールやウディタでターン制RPG以外のジャンルを制作するのには、実質的には限界があり、さまざまな制約が生じます。 ;具体的な手法 初期段階では関数や変数を活用してプログラミングし、処理速度を高める必要がある箇所にだけdefineマクロ等を用い別の方法に置き換える。C++ならinline関数という前処理命令もあります。 通常の関数で記述していったソースコードを、あとから一括変換などでdefineマクロやinline関数などに置き換えることは比較的に容易です。 また、関数を経由しているので、マクロを使った場合でも比較的にバグが混入しづらくなっているかもしれません。（defineなどの前処理命令マクロは、用いるとバグを発見しづらいので、なるべくマクロの利用を避けるべきなのが、ゲームプログラミングに限らないプログラミングの定石です。） 一方、まったく関数を使ってないコードを、あとからdefineマクロなどに手作業で置き換えるのは、なかなか面倒です。 最終的には一括変換で置き換えることが出来ますから、途中の段階では、処理速度を気にせず関数を使うのがいいでしょう。 なお、defineマクロは、値の置換以外には用いないのが、プログラミングの定石です。このため、たとえば黒色RGB値の<code>10,10,10</code>といった配列にdefineマクロを使うべきかどうか悩みますが、とりあえずなるべく値周辺にだけdefineマクロを適用するようにするようにするのが良いでしょう。いっぽう、一般の命令文をdefineマクロで置き換えるのは、避けるべきでしょう。 たとえば、処理に0.5秒ほどの時間の掛かってもかまわないような場所は、どんどん、関数に置き換えていっても良いかもしれません。 アクション性のないゲームなら、関数をぞんぶんに活用できます。 ターン制RPGやシミュレーションゲーム、アドベンチャーゲームなど、関数を活用しやすいでしょう。 一方、アクションゲームなどでキャラクター操作中のコードのように頻繁に使って、しかもそのゲームの中心的なコードなら、そこは最終的には関数にしないほうが良いかもしれません。 このように、ゲームのジャンルによって処理速度に対する必要な水準が異なりますので、プログラミング時における関数などの利用の方針も異なります。 以上のように、何でも関数にすることは避けるべきです。関数は処理速度の問題がありますので、必要性のある部分だけ関数にするべき。関数を使わなくても、for文やif文などのブロックの構成を適切に組み合わせることで、コード中のmain関数以降の部分でコード共通化できることは色々とあります。 「共通性のあるコードだから」といって、大して長いわけでもないコードを関数に置き換える事は、速度維持には寄与せず、ゲーム制作のプログラミングとしては、悪手となるでしょう。 ===2Dの画面出力=== 画面出力の場合も入力機器の場合と同じで、これらを操作する方法はOSごとに異なっています。先ほどあげた GTK+, Qt, SDLなどのライブラリはクロスプラットフォームの画面出力を提供しているため、これらを利用することで全てのプラットフォームで動くプログラムを作ることができます。<!--画面出力を扱うためには近年の[[w:ビデオカード|ビデオカード]]の発展についても見る必要があります。しかし、ビデオカードの機能は2次元の描画に関してはあまりあらわには見えないので、この話題は3次元の描画を行うときに再び戻ってきます。--> *[[ゲームプログラミング/ブロック崩し]] *[[ゲームプログラミング/画面出力]] ==目次== === ジャンル別のプログラミング手法 === ==== 3Dグラフィック ==== * [[ゲームプログラミング/3Dグラフィック]] * [[XNAを使用したシンプルな3Dゲームの作成]] ==== RPG ==== * [[ゲームプログラミング/RPG]] ==== アクション ==== ※未作成 ==== パズル ==== ※未作成 ==== シミュレーション ==== ※未作成 === ゲームのデバッグ === * [[ゲームプログラミング/デバッグ]] === 入力 === OSの種類によって、キーボード入力やマウス入力の受け付けのさいのプログラムの書き方は違う。 Windows API での具体的な手順は『[[ゲームプログラミング/入力]]』で説明する。 === ゲームエンジン ※未完成 === * [[ゲームプログラミング/Unity]] ※リンク先ページの編集者が現状ではUnityの著作･調査を放棄中なので、調べ物としては役立ちません（2021年12月19日に本文を記述）。 === 非プログラミングのゲーム製作の関連作業 === ==== バランス調整 ==== *[[ゲームプログラミング/バランス調整]] 厳密にはプログラミングの話題ではないが、ゲーム製作では必要な知識なので、サブページで説明する。 :※ゲームデザインに関する記述をここに集積し分離したい、という編集者の意図もある。 ==== ゲーム用の書類の書き方 ==== 説明書や仕様書（しようしょ）の書き方については、『[[ゲームプログラミング/書類]]』で解説する。 == 未分類 == ===Visual C++プログラムによる文字画像の出力=== Visual Studio付属のフォームデザイナ（VSの用意するGUI自動作成ソフト）によるGUIオブジェクト作成では、RPG用には使いづらい。いや、ひょっとしたら上手に使う方法はあるのかもしれないが、様々な理由で難易度は高い。 そこでまず、Visual C++で、フォームデザイナをなるべく使わずに文字や映像を出力する方法を考える。 選択肢は、幾つかある。 1.フォームデザイナを1つも使わない方式 *Windows APIで入力していく方法。(Wikibooksに『[[Windows API]]』の入門書があります。) *DirectXで入力していく方法。DirectX自体はWindowsAPIを利用している。 2.1つだけフォームデザイナのパネルを使う方式 *フォームデザイナで「パネル」という画像表示機能のコンポーネントを一つ用意して、そのパネルで表示する画像をゲーム内のストーリーなどに応じて切り替えるだけで、すべての画像表示を行う。 フリーソフトでゲーム用ライブラリの『HSP』はWindows API を呼び出す仕組みになっています(HSP関連のサイトを見ると、Win APIプログラミングの解説をしている場合もある)。 フリーソフトでゲーム用ライブラリの『DXライブラリ』は Direct X を呼び出す仕組みになっています。そして、ゲーム開発ツールのひとつであるウディタのソースコードは、DXライブラリとVisual C++ を使って書かれていると、作者が公表しています（ただしソースコードは非公開）。しかし、ウディタを用いたRPGプログラミングでは DXライブラリによるコーディングはしない。ウディタにはコード入力の機能は無く、マウス操作や、キーボード操作、キャラ名称や会話文などのテキスト文字や数値の入力のみに対応している。 ===乱数=== そもそも乱数とは何かという問題があるが、それは高度な数学的な議論になるだろうから、我々はその問題には深入りできない。 ゲームにおける乱数的な処理では、事実上ランダムな値にならず、演出や調整のためにアルゴリズムが介入している場合も多い。例えばゲーム中のくじで「外れ」続くと、当たり確率が変動し、次からは当たりやすくなるアルゴリズムなども良く使われる。<ref>『ゲームプランナー集中講座』、P232</ref>。 ゲームは娯楽であり、実用目的のシミュレータではないし、アルゴリズム介入で、確率的にもいんちきが多いので、あまり厳密なランダム性が問題になることは少ないだろう<ref>『ゲームプランナー集中講座』、P231</ref>。 例えばさいころというのは典型的な乱数器だし、ゲームにもよく使う物だろう。 無印C言語には標準的乱数関数 rand()があるが、これを乱数発生に使うことに批判的な意見もあるし、機能もやや不足していると見れる。 Windows64bit では int rand(void) の出力は 32bit 整数だろう。まず stand関数で初期化してから rand()を呼ぶごとに疑似乱数が帰ってくる。これの複数回の連なりが乱数列だね。帰ってくる値は0 以上 定数RAND_MAX の値以下。 例えばさいころの数値が欲しいなら、rand の返り値を6で割った後、余りに1足せば、とりあえずそれらしいものはできる。 RAND_MAXは rand()の属性として定数が与えられているだけだから(Windowsで0x7FFF)、この値の変更はできない。 まあこれでもそこそこいい加減な乱数として機能するだろうが、最近ではもう少し改良された、質の高い乱数関数もある。 また、改良された乱数関数は、乱数の範囲も指定できるから何かと使い勝手が良いし、バグを防ぐ効果もあるのだろう。 <syntaxhighlight lang="cpp"> Random^ saikoro1=gcnew Random();// Random^ でRandomクラスの変数を作っている。gcnewはインスタンスをつくるための演算子。 int detame; detame=saikoro1->Next(1, 7);// Next メソッドで「〇〇以上△△未満」の乱数を指定できる。「->」はメンバーアクセス演算子。 MessageBox::Show("目"+detame.ToString()+"が出ました。"); </syntaxhighlight> ↑例えば上述のコードは前編集者が示したものだが、これは .NETプログラミングですね。.NET のSystem::Randomクラスを使っている。.NETのクラスは普通、C#かVisual Basic で利用するので、Visual C++で使えるようにするには結構面倒な手管がいるが、その辺は読者諸兄、ヘルプやネット情報を参照して、適宜辿り付いてほしい。 C++ の場合はむしろ、 #include <random> を宣言してそこで使える関数を使用するほうが簡単でしょうね。この場合でも、乱数としての精度も高いし、帰り値の範囲指定もできる。 ===画像のちらつき=== 画像がひんぱんに変化するアプリでは、画面が、ちらつく事がある。画面のちらつきは、ゲームのように、画像を凝視するアプリでは、かなり利便性を損なう。 キャラクターが1歩移動するだけで、画面全体がちらついたりする場合もあり、かなり、プレイヤーの不満になる。 これは、ダブルバッファ（「裏画面」と、良く言われる）という技術で、解決を図る。 Direct Xの用語では「スワップ チェーン」と呼んでいる。 .NET Framework開発環境の C++や C#でもダブルバッファの機能があると解説されている。いくつかのGUIオブジェクトのプロパティで、ダブルバッファの設定項目がある。 しかし前編集者が実験したところ、この機能を有効に使って確認することはできなかったとの指摘がある。ひょっとしたら何らかのマイクロソフトの解説に間違いがあって、工夫次第では利用できるかもしれないが、少なくとも今現在のこのページでは、その問題に関するリファレンスは提供できない。 そこでやはり、以前の項目と同様、Win32 API または DirextX の利用をこのページでは考えたい。 前編集者は、.NET Framework のフォームデザイナでは、ちらつき自体は解決できそうだが、グローバル変数の共有が困難だったり、アプリ内から終了コマンドが使えない、などの難点があると指摘している。 ただ現編集者はこの2点に関しては、解決策はあると思うが、しかし特に調査はしない。 前編集者は、.NETプログラムでゲームを作る難点をいくつも上げているが、おそらくどれも、.NET の仕様や全貌に精通すれば解決できるように思えるが、そもそもその全貌がかなり広大なので、解決の道のりは長いだろう。 そこで少なくともこのページでのWindowsゲームプログラミングは、Win32 API を利用したものになるだろう。 ==セーブ、ロード、データベース== ===セーブ機能とロード機能の作り方=== ゲームでもシリアライズ機能が必要なことは多いだろう。数値（HPなどの各種パラメータ現在値）や文字列（例えば、プレイヤーの作成したキャラクターの名前）や現在地やフラグ状況などなど、セーブの機能は欲しい。一番簡単な方法は、C言語の fopen 関数のテキストファイル書き込み機能で、テキストファイルとしてセーブすることだろう。 Windows API には CreateFile関数 があるが、テキストファイルでの素朴なセーブは一番簡単で単純なセーブ法だろう。そしてテキストファイルを読み込んでプログラムに各種変数を配置して、ロードとする。 書き込みとしては、一番単純なC言語記法では、fprintf ですかね。C++としての書き込みをしてもいいし、読み込むのも、一番基本的な方法で。基本Cだとしたら fscanf で、この関数でテキストの数値も変数として読み込めるはずですよ。場合によっては atoi関数 で文字列→数値の変換をすることもありますかね。 基本的にデータファイルは、OS もアプリケーションも、テキストファイルとバイナリファイルの２分類で考えるでしょう。でもテキストファイルだってバイナリの集まりなんですが、テキストを扱うファイルだけ特別視していると考えていい。 そして多少それらしいデータを作りたいときは、バイナリファイルで作るという事になるでしょう。 バイナリファイルでもデータとしてのファイルと、OS が機械語または何らかの仮想的な機械語として扱う実行ファイルがある。それらのバイナリは種類に応じて多くは冒頭にファイル識別子の情報があるだろうし、OS や アプリケーション側で工夫を凝らして、特定の条件を満たす場合しか動作しないようにしているだろう。そしてバイナリファイルを扱うときは、セキュリティの安全性も考慮するだろう。 基本的にプログラム側は何でもありだが、識別子の判別その他、ある程度様々な考慮をしないと、困った事態が起こり、プログラマーが責任を問われることも起こるかもしれない。 まあその時はいつものように口先だけで謝り、それでも許してくれなかったら、腹をかっ割いて死んでお詫びすれば、世間の人たちは美事な武士道精神と言って、口々に褒め称えてくれるだろう^^。←もちろんこれは冗談^^;;;。 市販のパソコン用ゲームや同人ゲームでは、テキストファイルではなくバイナリでデータ保存するゲームの方が圧倒的に多いだろう。その方がそれらしいしかっこがつく。ゲーム開発ツール側自体も、そうなっている場合が多い。RPGツクールもウディタも、セーブデータの形式はバイナリ。 テキストデータは基本エディタで開けるが、バイナリデータも内容によっては結構ぐちゃぐちゃの状態で開ける。バイナリデータはバイナリエディタで開ける。バイナリエディタのリードオンリーモードやバイナリビューアみたいなものがあれば、データーを壊さないで結構安全にデータ調査できる。 データ内容を秘匿したければ、バイナリ化だけではなく、暗号化も必要になるかもしれない。 ===機能の整備=== セーブ&ロード機能の実装時には、まずセーブ機能から作るのがやりやすいという。 しかし最終的には関係関数の整備は、ロード機能が基盤となるだろう。 データや変数を、一定のスタイルでセーブして、一方で正しいスタイルでロードする、この機能が必要なわけですよね。 シリアライズされたデータを、型を決めたうえで配置しなければいけないから、ロードのプログラムの方が複雑に、面倒になる。 結局データのシリアライズは、ロード機能が基盤となり、その機能の作りやすさが、セーブ機能の作りやすさも支配するようだ。 == ゲーム中の特殊イベント == *[[ゲームプログラミング/特殊イベント]] RPGやシミュレーションゲームで、1回しか起きない特殊イベントを作りたい場合もありますね。例えば日本の中世の戦国シミュレーションゲームで、「桶狭間の戦い」が3回も起きたら困りますよね。まあ起きるなら起きてもいいけどね^^。信長君には敦盛を3回舞ってもらいましょう^^。 さて、リンク先ではその話題についての叩き台、「こうプログラミングしたら、いいんじゃない？」、という事を説明しています。 ==スケジュール管理== [[File:Tokai Hairo.jpg|thumb|500px|ガントチャートの例:東海発電所の廃止解体工程]] 個人でゲームを作る時にはあまり考慮しなくていいのですが、シビアな仕事の世界では、スケジュール管理表が良く使われます。 「作業責任分担表」（TRM:Task Responcibility Matrix）といわれるスケジュール表から、それをグラフ的に図示したガントチャートといわれる表を作って、その表を見て作業計画を判断する<ref name="gpd65">川上大典ほか著『ゲームプランとデザインの教科書』、秀和システム、2018年11月1日第1版第1刷、P.65</ref>。 {|class="wikitable" style="float:left" | 仕事 | 担当 | 状態 | 開始 | 終了予定 | 終了日 |- | 仕事1 | 田中 | 済 | 2021/10/03 | 2021/10/10 | 2021/10/10 |- | 仕事2 | 田中 | 仕掛 | 2021/10/11 | 2021/10/13 | |- | 仕事3 | 鈴木 | 済 | 2021/10/05 | 2021/10/08 | 2021/10/08 |- | 仕事4 | 山田 | 未着手 | 2021/10/13 | 2021/10/17 | |- |} {{-}} ガントチャートでは普通、横軸に日程をとります。 商業ゲーム界でもガントチャートの横軸は日程です<ref name="gpd65" />。 ガントチャートとして図示することで、ボトルネック、リスク要素、直感的にスケジュールの詳細や全体像が理解しやすくなります<ref name="gpd65" />。 スケジュール管理のための、現実的、習慣的な工夫ですね。 このTRMとガントチャートは、IT業界だけでなく建築工事でも使われ、これを利用したボトルネックの洗い出しも、建築学の教科書に記述があります。 住宅の新築やリフォームをする時、建築業者がこの表を提示して、見せてくれることもあるでしょう。 業界人ではなくとも、こういう慣習を知っておくと、得るものがありますよね。 ==ストーリー制作、そして順序== ゲーム界、特に商業ゲーム界では、ストーリーもゲームも全体から作っていくようです。アトラス社（ペルソナシリーズ、女神転生シリーズ、などを手掛ける）では、「ゲーム全体に血を回すのが先」、という言葉が良く言われていました<ref>[https://news.denfaminicogamer.jp/projectbook/191030a/2]2020年12月1日に閲覧して確認.</ref>。 プレーヤーが見たいのは、物語の細部ではなく、ゲーム全体のストーリーやテンポ、総合像である、とは限らないのだが、しかし物語を含む創作物では、全体を見て重視し、そこから作っていくのはある意味王道、常套手段ではあります。 ちなみにやや雑談的ですが、日本の週刊漫画は、その週その週での勢いや読者の興味の引き付けも大事なので、全体がないのに、その場その場で場当たり的に作られた事も多かったようです。 現編集者が聞いたことのある話では、週刊少年ジャンプで連載していた本宮ひろ志氏が、不良少年物の漫画で、敵の不良少年グループと1対1000の喧嘩になり、さあいよいよ対決場に着いて勝負だってところで以下次号にし、そして実は本宮氏はその続きを全く考えていなくて、考えてみたけどどう考えてもどう描いていいかわからない^^;;;、そこで仕方ないのでイライラして近所の酒場に飲みに行き、そしてイライラしたままそこの常連達とあり得ない大ゲンカして^^;;、そのままボロボロになって家に帰って、2時間で次の号の漫画を描き終えた、と、本宮氏自身がメディアで語っていたのを聞いたことがあります。 さて、コンピューターゲームである以上、ゲームのストーリーはシステムと連携、調和したものになるでしょう。 そこで、ゲーム作家として、システムを先に決めた後ストーリー、そういう方法論の作者も多いようです<ref>川上大典ほか著『ゲームプランとデザインの教科書』、秀和システム、2018年11月1日第1版第1刷、P.306</ref>。 とにかく商業ゲーム界では常識的に、全体像から攻めていく。 例えばドラマ脚本では、「ハコ書き」という方法がある。全体像に当たる「大ハコ」を記述してから、「大ハコ」→「中ハコ」→「小ハコ」と記述していく<ref>川上大典 ほか著『ゲームプランとデザインの教科書』、秀和システム、2018年11月1日第1版第1刷、P.184</ref>。 しかし、本当にすべてのゲーム制作は全体から作る必要があるのか、という疑問はありますが、その方法論に従うとすると、 :*エンディングを大まかに先に作る :*機能の実験を簡易でいいので事前にしておく（※プロトタイプの項目を参照） :*使用頻度の高い部分から作る などの工夫を凝らして、常識的な方法を遂行していくことになるでしょう。 或いは、アルファ版（α版）を中盤から作り始めるとか…<ref>吉冨賢介『ゲームプランナー入門』、P17</ref>。α版の製作目的の一つとして、そのゲームが本当に面白いかの検証がある。面白くないと判断したら、制作中止もある。最初からではなく中盤から作ると、ゲームの全体像が見えるので、検証、判断がしやすい。 つまり全体から攻めて、細部やゲームが作られていくわけですから、必ずしも冒頭部から作り始める必要はないわけです。 ;エンディングやラスボス戦闘を早めに作る場合 ゲーム作者にもよりますが、商業ゲームシナリオでは、エンディングを早い時期に作る人も多い<ref>畑大典ほか著『ゲーム作りの発想法と企画書の作り方』、総合科学出版、2020年11月19日第1版第1刷発行、P166</ref>。 システム面についても、先にゲーム全体のクリア条件を決めてから、あとから各ステージの条件を決めていくことが多いようです<ref>川上大典ほか著『ゲームプランとデザインの教科書』、秀和システム、2018年11月1日第1版第1刷、P.253</ref>。 エンディングの仮の、おおざっぱなシナリオ、そしてキャラクターの性格付けを先に決めておくと、ゲームの方向性と主人公達が目指すもの、ゲームの全世界像が作者やスタッフに明快になっていきます<ref>畑大典ほか著『ゲーム作りの発想法と企画書の作り方』、総合科学出版、2020年11月19日第1版第1刷発行、P166</ref>。 基本的に商業ゲーム界では、全体→部分と細部、の構成を進めていきます。 ゲームは必ず最後にラスボスと戦う訳では無いでしょうが、その戦いはゲーム中で最も高負荷になるでしょうし、全てのシステムが集積する場面でもあるので、エンディングを先に作ると、ゲームの最大負荷の検証ができます<ref name="yth">[https://www.youtube.com/watch?v=kAUkSNhH410] 2020年8月30日</ref>。 3Dゲームでは、RPGなら戦闘シーン、アクションゲームならアクションシーンが、一般的に最も高負荷<ref>ntny著『ローポリスーパーテクニック』、ソフトバンククリエイティブ、2010年2月16日初版第5刷、P28</ref>。 負荷が高くて処理が落ちないかどうかも、この方法で確認できます。 まあ全ての物語は最後の最後が一番の見せ場ですからね。 中盤は重要性が低い…訳では無いが、少し手を抜いておこうという事か^^;;;。 最後は見せ場を盛り込むから、物語を削る必要があるとすれば、それ以外の部分、という事になりますよね<ref name="yth" />。 つまりラスボス戦（必ずゲームってこれで終わるの? ^^;;;）は最重要なので削らない。後の部分は削る可能性あり。だから最後を先に作って作りこんでおけば、制作過程で不測の事態が起こっても、重要部分はできているので、早く、上手にリリースできる。 {{コラム|イラスト制作でも順番を考え直すと打開できる場合あり。| イラスト雑誌『コミッカーズ』（1995年季刊夏号）（唯 登詩樹 表紙）での藤島康介のインタビュー 藤島（談）:よく若い漫画家さんから相談で、「先生みたいに女性の長い髪を書くとき、毛先を書くのが難しいです。根元は書けるのに」との相談を受けるのですが、 僕（藤島）は髪を描くときは毛先から始めて根元に向かって描いてます。 つまりイラスト初心者は、根元から髪の毛を描きたくなるのですが、ここで長い髪の毛を描く場合はむしろ毛先を先に書いて位置決めして、長い毛を描くと割とうまく描ける。 きれいな女性の髪の毛は、毛先の奇麗さが大事ですからね。 ストーリーを作る時に全体を考えたうえで、必ずしも最初から書くことにこだわらない方がいいように、絵を描く時にも同じ発想が有効になる。例えば機械製図でも、正確に奇麗に書くためあるいは実際の製作のため?、位置決めの優先指示の記法がある。 }} *目標 世の中では目的や目標を明確化せよ、と主張する人は結構多い。現編集者は懐疑的。むしろ他人を自分の都合いいように動かしたいから、その方向を明示したいのだろう。それより、我々の本当の目的と目標は何か、歩みを止めてちょっと考えてみろよ、と、言いたい。 しかし結局世の人たちは目標をはっきり、言語化したがる。ゲームでもそれをすると、プレイヤーがゲームに引き込まれる、と言うが、実際にはそれはゲーム業界のカモになっている、インチキゲーマーだけだろう。 とにかくカモたちは目的を欲しがる。目標や課題がゲーム中で明確になっていないと、疑問だらけになり、ゲームをやめて、業界にお金を落としてくれない。そこで設計の際、各ステージやエリアなどの冒頭で、そのステージの課題や目標などを明示する必要があるという<ref>『ゲームプランナー入門』、P39</ref>。 ファミコンなどの古いアクションゲームではゲーム本編では目標は語られていませんが、しかし説明書などではきちんとそれが語られており、実際にスーパーマリオブラザーズの第1作目の説明書では、目的はクッパを倒してピーチ姫を救出することだと語られています<ref>『ゲームプランナー入門』、P54</ref>。 === その他の開発順序 === ==== チュートリアルの細部は後回し ==== :※ 特に出典は無いですが、技術系の仕事では常識的な考え方です。 RPGやシミュレーションゲームなど、プレイヤー視点では、ゲームの始めのほうに操作説明などのチュートリアルのイベントがありますが、しかし、実はチュートリアルの細部は、作るのが後回しになる場合が多々あるかと思われます。 なぜなら、ゲームで仕様を変更するたび、チュートリアルも変更の必要が生じるからです。このため、チュートリアルのとりあえずの完成の時期は、けっこう後回しになります。 よほど仕様の単純なゲームなら別ですが、そうでない場合、あまり開発初期からチュートリアルの細部を作りこみすぎないようにするほうが安全でしょう。 そもそも、チュートリアルをゲーム本編に組み込み必要もありません。たとえば説明書などで、細かい説明を代用する事だって可能なわけです。 チュートリアル部分に深刻なバグが発生してないかとか、逆に本編ゲーム中にチュートリアルが異常起動しないかなどの確認のために、開発初期からチュートリアルを組み込んでも構いません。ですが、おそらく、最終的なチュートリアルの完成時期は、仕様やゲーム全体像が本当に完成・確定したあとの時期なので、ゲーム本編の完成間近の時期になるか、もしくは本編完成後になるでしょう。 == 古典ゲームと技術限界 == ゲームを作る際、過去の名作ゲームを参考にしようと思うでしょうが、 しかし過去のゲームの設計は、当時の性能の限界に影響を受けているので、 果たして現代のコンピュータ性能の飛躍的に上昇した時代でも過去の設計をそのまま参考すべきかは、 やや検討の余地があるでしょう。 歌舞伎などの古典技芸の伝承の格言で『師を見るな、 師が見ているものを見よ』という教訓があると言われています。 このセクションでは、主に1980年代のファミコン時代のゲームを例に説明します。 === スプライト === ファミコン時代の昔のゲーム機には、一画面に表示できるキャラチップ数（敵チップも含める）に上限がありました。 一画面中に表示できる限界は、だいたい、マリオが一画面中に数十人ぶんです。（実際の数値については、本ページでは触れない。説明の本質には関係ないので。） ファミコンでは、このような仕組みを 「スプライト」と呼んでいました。（実はマリオ1体の表示の時点で既に、いくつかのスプライトの小単位を合成したものになっているのですが、説明やややこしくなるので、このページでは触れません。） ともかく、実は昔のゲームのステージ設計は、スプライトの制限を前提にしたものになっています。 極端なハナシ、もしたとえばシュテイングゲームなどで、動く敵100体をボムで一瞬で倒せるようにしたゲームを設計しようとかファミコン時代に思っても、 ファミコンではすでに敵100体の表示の時点でグラフィック性能的に原理的に無理なのです。 どうしても敵100体を表示したい場合、表示のタイミングを変えます。 たとえば、 :1タイミング目では0～10体目までのAグループを表示、 :2タイミング目では11～20体目までのBグループを表示、 みたいにして、タイミングを変えることで、なんとか表示するのです。 このため、画面上に動くキャラクターが多いと、一瞬、ほかのキャラが消えるのは、裏側でこういうタイミング切り替えの処理が行われているからです。 説明の都合上、本ページではキリのいい「10体目」までと 上記の例では表現しましたが、実はファミコンの制限はもっときびしく、横1列上には8体目までしか表示できないと言われています。（しかもマリオ1体自体が、じつは2体×2体の計4体チップを使っているといわれる。なのでマリオ5体は同一ライン上には表示できない。） なおシューテイングゲームの場合、敵チップだけでなく、敵味方の双方の弾丸もチップを利用しますので、実際の制限は上記の数値例よりも、もっと厳しいでしょう。 また、プレイヤー視点ではキャラクター1人にしか見えていなくても、背の高いキャラクターなどはキャラクター2体以上に相当するなど、注意しなければならないこともあります。 だからファミコン時代のアクションゲームで、巨大ボスのいるステージでは、ボス以外の敵が出現しないのは、おそらくですが、プレイヤー視点では1体のボスに見えても、内部プログラム的には敵チップを何体ぶんも利用しているのでしょう。 しかも巨大ボスは、ゆっくりとしか動きません。 おそらく、そのゆっくりとした時間内にVRAMを書き換え中だったのでしょう。 日本ではコトワザで「ウドの大木」みたいな言葉があるので、なんとなく巨大ボスがゆっくりと動いても不自然ではないかもしれませんが、よくよく考えたら現実世界の大男はけっこう動きが早いです。（レスラーやヘビー級ボクサーなどを考えれば分かるでしょう。） === 書き換え速度と背景グラ === ファミコンのマリオでは、書き換えの手間を省くために、一説には、たとえばマリオ1の地上ステージの世界の空の青色は、実はほとんどの場合、マリオが横スクロールしても空の青色の部分は書き換えをしておらず、横スクロールする前の青色をそのまま使いまわしていると言われています。 なぜそれで効率化できるかというと、ステージ中の障害物はほとんどのステージの場合で、画面の比較的に低い位置に障害物があるので、その低地の障害物だけを書き換えすれば済むからです。 だからファミコン時代では、こういう理由から、ステージの背景グラフィックや、障害物配置なども決まっているでしょう。 だから果たして、現代でもそれを過去の名作のステージ構成を踏襲すべきかどうかは、分かりません。もちろん、仕組みを分かった上で真似るのなら、それは特に問題ないでしょう。 === アナログテレビの にじみ === ブラウン管では、細かすぎるドットは表示が、にじみます。ゲームに限らず、テレビアニメや一般の実写番組などでも同様、にじみます。（どのように、にじむかは、専門的なので説明を省略する） だから、ファミコン時代から、だいたいプレステ1時代のゲームのグラフィッカーは、このことまで意識してドットを描いているはずです。 ともかく、液晶テレビとブラウン管テレビでは、同じ画像データでも表示結果が変わります。 レトロゲームから勉強する際は、ファミコン〜プレステ1時代のレトロゲームでは、データ上の解像度よりも実際のディスプレイ上の映像は細かいことに気をつける必要があります。 たとえば滲み（にじみ）を意図的に利用することでテレビの解像度以上の表現をしていたりしていました。 また、ファミコンのドットは縦横の長さが縦方向と横方向とで長さが違うので、そこまで考慮して、グラフィッカーは絵を描いています。 また、ドットの図形的な細かさだけでなく、色についても、にじみによって、当時のゲーム機の色用のビット数の限界を超えた表示をファミコン時代から行っていました。 つまり、同じドットの黄色の単色でも、そのドットの幅が1ドットか2ドットかで、テレビ上で表示される色が違います。「色が違って見える気がする」ではなく、実際にブラウン管のディスプレイ上では色が違うのです。言い方を変えると、ブラウン管テレビでは元の画像データ通りには色は表示されていません。（さらに縦方向と横方向とで色のにじみ方が違うが、専門的すぎるので、説明は省略する。wiki書くために調べるほうも大変なので。） なので、もし現代の人がファミコン当時のゲーム作品のグラフィックを参考にする際は、このことに気をつける必要があります。一番、手軽なのは、そもそもグラフィックの細部については参考にしないことです。 これはつまり、もし公式エミュレーターなどでファミコン時代の古いゲームを、現代の液晶ディスプレイ用のゲーム機でプレイしても、エミュレーター側で過去テレビのグラフィック特性の再現のための特別な工夫をしてないかぎりは、実はグラフィックの表示結果が当時のものとは異なるわけです。 一方、パソコン市場では、ノートパソコンの普及し始めた1999年頃には液晶ディスプレイのものが比較的に安価で出て来たので、この頃からパソコンゲーム市場では次第にブラウン管のにじみを考える必要が無くなったでしょう。 なお、アナログテレビはそもそもテレビ自体の解像度が低いので、プレステ2時代あたりからのゲームには合いません。だから、プレステ2時代あたりからは、あまりブラウン管の特性を考える必要はなくなります。 逆に言うと、あまり指摘されないことですが、プレステ2時代の当時の人が当時の最新ゲーム機をプレイするには、もし既存のアナログテレビを使い続けていた家庭は、テレビ受像機そのものを買い換える必要があったという亊です。 一応、家電量販店などでテレビ用のアナログ／デジタル信号の変換機などを購入してテレビに接続するなどして使えば、デジタルテレビ用のゲーム機もプレイ可能ですが。 だからアナログ放送自体は2010年くらいまで続いたとはいっても、あまり当時のゲーム機をアナログ用テレビでプレイしていたとは考えにくくはあります（プレイヤーの好みによる）。 アナログ停波以降の時代である2010年以降の現代では、もうテレビ番組の受像でもブラウン管は一切用いられていないので、もはや現代のコンテンツ制作では特に考える必要はありません。 ブラウン管自体のドットの縦横が違っている。 このため、ブラウン管を前提にしたゲーム機やパソコンはそれに対応するために画像データ側のドットの縦横比が違っている。 ゲーム機やパソコンの種類、さらにはアーケードゲームの基盤といったハードウェアの種類ごとに、コンピュータ側でのドットの縦横比の管理は違っている（らしい）。このため、移植のたびに、ドットは書き直しになったようだ。 古いゲームの制作では「ドット用紙」という方眼紙のような印刷書面がある（らしい）のだが、そのドット用紙の時点で1マスの縦横比が少しだけ違い、1マスが長方形である。1ドットだけでは長方形であるのに気付かないかもしれないが、しかし「ちりも積れば山になる」ように、何十や百ドットも積み重なれば、縦横の長さは大きく違ってくる。 現在のパソコン用のドットエディタ（という画像制作ツールがある）は1ドットが正方形であるが、しかしファミコン時代は1ドットが（ドット用紙の時点で）少しだけ長方形である。（なお、画像制作ツールそのものの作り方については、『[[ゲームプログラミング/画像ファイルの作成プログラム]]』で説明する。ゲーム制作では普通は必要ないが、知識として。） ファミコンの色数制限は52色から4色×4パレット（1パレットあたり4色）を使えると言われている<ref>[https://mynavi-creator.jp/blog/article/history-of-2dcg-designer 『2DCGデザイナーなら知っておきたい2DCGゲームの歴史』 2017/8/21 マイナビクリエイター編集部 ] 2021年12月30日に確認. </ref>。しかし実際には、4色のうち1色は透明色として利用される色であり、全パレット共通の色である（なので3×4=12色になることのいなる）。スプライトのパレットとは別に背景のパレットがあるので実際には、もっと16色以上の多くの色数が一画面内で使えるが、しかしその他のさまざまな制限があるので、合計で一画面内で25色が使えると言われる（12 × 2+1 = 25）。 しかし実際には、ブラウン管の滲み（にじみ）を利用しているので、当時のプレイヤーには1パレットだけで描かれた1キャラのキャラチップ内でも3色以上の多くの色が見えているだろうし、画面全体でも25色内にない色がプレイヤーの目には映っていることになるし、もしかしたら52色にない色がプレイヤーには見えているかもしれない。なお、スーパーファミコンの色数制限は32,768色から16色8パレットであると言われている。 レトロなゲーム機では、さらにメモリ容量やストレージ容量などの制限もあり、けっして仕様上の最大色数を気軽に利用できたわけではないだろう。こういう制限もあったからか、ネットではファミコンの色数が「4色」やら「8色」、スーパーファミコンの色数が「16色」や「256色」などとも言われることもある。 {{コラム|「ドット絵」とは| よく世間には、ファミコン時代のゲームの、ゲーム中での絵柄のことを「ドット絵」という人がいます。プレステ1やセガサターンのポリゴンによって、「ドット絵」が無くなったと思っている人もいます。 しかし現実には、プレステ以降でも、顔ウィンドウの顔グラフィクや、キャラチップなどのグラフィックでは、その制作時にドット単位のグラフィック指定は行われています。 たとえば装備品で武器の横に小さい剣の絵などのアイコン画像が書かれている作品などもありますが、こういったアイコン画像もドット単位の指定で描くでしょう。 こう指摘すると、「プレステ1以降のゲームは解像度が高い」とかよくわからない反論をする人がいますが、しかし「ドット」という工学用語のどこにも、「解像度が低い」とかの意味はありません。また、「ドット」というのをブラウン管ディスプレイの映像だと思ってる人もいます。 しかし、液晶ノートパソコンの普及した2001年以降の液晶モニターの時代ですら、 「液晶のドット欠け」などのように「ドット」という用語は使われます。 「ドット」というのは、けっしてゲーム用語ではなく、「液晶のドット欠け」のように電子工学などですでに意味が決まっているので、ゲームオタクの戯言（ざれごと）は「ドット」の意味には無関係です。 さて、プレステ1以降のゲームでもキャラチップなどでは、ドット単位の指定が行われるのでした。 それどころか、携帯ゲームソフトでは、ガラケーの時代から既にドット単位の指定は現役の手法であり、スマホゲーム時代の現代でも現役です。 だから「ドット絵には魅力がある」とかいって、ファミコン時代のゲームばかりあげる人は、こういう現役のドット絵作家の努力が目に入らない人ですので、なるべく信用しないほうが良いと思います。 また、画像編集のフリーソフトまたはシェアウェアで、現代でも「ドット エディタ」と呼ばれる種類の画像制作ソフトがあり、少なくとも2D同人ゲームの制作ではよく使われます。 ツクールやウディタのドット絵を作る場合でも、ドットエディタを使って作るわけです。 ゲームに興味なさそうな人が「ドット絵」をレトロゲームの絵という意味で使うのは仕方ないかもしれませんが、しかしゲーム通みたいな顔して「俺ってけっこうオタクなんだぜ」みたいなフリしてるのに、レトロ的な用法で「ドット」という言葉を使う人はアレです。 おそらく、本当はけっしてドット絵が好きなんじゃなくって、単に自分の子供時代の思い出が好きなだけだと思います。 ニュアンスは違いますが、アニメ評論でもそういう話があります。1990年代後半に岡田斗司夫と誰かの対談で（おそらく書籍『マジメな話』での対談）、 「アニメの黄金期はいつか？」というよくあるアニメオタク談義について、 対談相手が言うには、 よく「70年代だ」「いや80年代だ」とかで議論が始まるが「いや12歳だ」というオチが有名だと。 }} === アナログテレビの焼きつきなど === あまりゲーム評論では指摘されないのですが、 このほか、ファミコン時代はテレビ受像機がアナログのブラウン管ディスプレイなので、 あまり長時間、同じ色をディスプレイ上の同じ位置に表示し付けていると焼きつきが起きる可能性があるので、 ステージごとにコンセプトになる背景色を変えたり、 あるいはステージの背景色を黒にしたステージを増やしたりとかの工夫も、必要だったかもしれません。 ゲームではないですがパソコンソフトなどの古いソフトは、こういったディスプレイの焼きつきの事を考えており、だからスクリーンセーバー機能の搭載など何らかの対策をしています。 ともかく、あまり、特定の色ばかり続けて使いすぎないようにする工夫が必要だったでしょう。 アナログテレビは西暦2010年のアナログ停波する時代まで使われていたので、焼きつき問題はファミコン以降のプレステ1～2時代のゲームにも関係するでしょう。 ネット上にはデマで「ブラウン管だと焼きつきが起きない」（×）というデマがあるが、しかし西暦2001年くらいの筐体パソコンのモニターはまだブラウン管が多かったし、その時代からすでに焼きつき防止のためにスクリーンセーバーがWindowsに搭載されていた。だからデマ「ブラウン管だと焼きつきが起きない」（×）にダマされないように。 なお、現代のテレビ受像機には、焼きつき防止のためにすでに「ピクセルシフト」という機能があって、 これは画面上の映像の表示位置をタイミングによって微妙にズラす機能です。こういう機能がすでに搭載されているので、わざわざゲームソフト側で実装する必要はない。そもそも液晶モニターは、焼きつきが起きにくい。ただし有機ELはどうだか、まだ新しい技術なので分からない。 == 脚注 == <references /> == 関連項目 == * [[ゲームプログラミング/コンピュータゲームの種類]] * [[XNAを使用したシンプルな3Dゲームの作成]] * [[プログラミング]] * [[w:ゲームプログミング]] {{DEFAULTSORT:けえむふろくらみんく}} [[Category:ゲーム]] [[Category:情報技術]] {{NDC|007.64}} jkjyvy6rh8ia0255gdxax86hyrxsfrv 0 4778 205916 67243 2022-07-27T20:40:25Z Rhkmk 66092 /* 判例 */ wikitext text/x-wiki [[法学]]＞[[民事法]]＞[[民法]]＞[[コンメンタール民法]]＞[[第2編 物権 (コンメンタール民法)]] ==条文== ([[:w:指図による占有移転|指図による占有移転]]) ;第184条 :代理人によって占有をする場合において、本人がその代理人に対して以後第三者のためにその物を占有することを'''命じ'''、その第三者がこれを'''承諾'''したときは、その第三者は、占有権を取得する。 ==解説== 民法上の[[w:引渡し|引渡し]]の一類型。 [[w:現実の引渡し|現実の引渡し]]の場合と違い、外観上占有形態は変わらないため、公示のための手続が必要となる。 ==参照条文== *[[民法第178条]]（動産に関する物権の譲渡の対抗要件） *[[民法第182条]]（現実の引渡し及び簡易の引渡し） *[[民法第183条]]（占有改定） ==判例== *[http://www.courts.go.jp/search/jhsp0030?hanreiid=56202&hanreiKbn=02  所有権確認請求] (最高裁判例 昭和34年08月28日)民訴法566条 *[http://www.courts.go.jp/search/jhsp0030?hanreiid=55169&hanreiKbn=02 第三者異議](昭和57年09月07日 最高裁判例)[[民法第192条]]、[[商法第597条]] *:寄託者が倉庫業者に対して発行した荷渡指図書に基づき倉庫業者が寄託者台帳上の寄託者名義を変更して右寄託の目的物の譲受人が指図による占有移転を受けた場合には、民法192条の即時取得の適用がある。 *[] (最高裁判例 ) ---- {{前後 |[[コンメンタール民法|民法]] |[[第2編 物権 (コンメンタール民法)|第2編 物権]]<br> [[第2編 物権 (コンメンタール民法)#2|第2章 占有権]]<br> [[第2編 物権 (コンメンタール民法)#2-1|第1節 占有権の取得]] |[[民法第183条]]<br>(占有改定) |[[民法第185条]]<br>(占有の性質の変更) }} {{stub}} [[category:民法|184]] n9b4a6einqd8wuba732vw8hswau8j2x 0 6538 205921 163270 2022-07-28T03:25:47Z 118.21.117.149 /* 条文 */誤字集成 wikitext text/x-wiki [[法学]]＞[[民事法]]＞[[商法]]＞[[コンメンタール商法]]＞[[第2編 商行為 (コンメンタール商法)]] == 条文 == （買主による目的物の検査及び通知） ;第526条 # [[w:商人|商人]]間の[[w:売買|売買]]において、買主は、その売買の目的物を受領したときは、遅滞なく、その物を検査しなければならない。 # 前項に規定する場合において、買主は、同項の規定による検査により売買の目的物が種類、品質又は数量に関して契約の内容に適合しないことを発見したときは、直ちに売主に対してその旨の通知を発しなければ、その不適合を理由とする履行の追完の請求、代金の減額の請求、損害賠償の請求及び契約の解除をすることができない。売買の目的物が種類又は品質に関して契約の内容に適合しないことを直ちに発見することのできない場合において、買主が六箇月以内にその不適合を発見したときも、同様とする。 # 前項の規定は、売買の目的物が種類、品質又は数量に関して契約の内容に適合しないことにつき売主が悪意であった場合には、適用しない。 == 解説 == 本条は、商人間の不動産売買についても適用されるか。 条文上、不動産は排除されていない。裁判例においても、本条が不動産売買に適用されることを前提とした上で、特約により本条の適用が全部または一部で排除されるのかが、争点となっている。事案として、マンション用地の受領後、6か月経過後に土壌汚染が判明した場合の、土壌汚染対策費の負担を売主が負うか否かが争われている。 不動産実務上、本条は買主にとって不利な規定なので、買主は不動産売買契約に際して、本条を適用しない旨の条項を売買契約に入れることを要請する場合がある。 == 判例 == * [http://www.courts.go.jp/app/hanrei_jp/detail2?id=57252 自動車残代金並びに附属品代請求](最高裁判例 昭和29年01月22日)[[民法第570条]],[[民法第566条]] * [http://www.courts.go.jp/app/hanrei_jp/detail2?id=54885 石炭代金請求](最高裁判例 昭和35年12月02日) * [http://www.courts.go.jp/app/hanrei_jp/detail2?id=62049 売掛代金請求](最高裁判例 昭和47年01月25日)[[民法第415条]],[[民法第570条]] ---- {{前後 |[[コンメンタール商法|商法]] |[[第2編 商行為 (コンメンタール商法)|第2編 商行為]]<br> [[第2編 商行為 (コンメンタール商法)#2|第2章 売買]] |[[商法第525条]]<br>（定期売買の履行遅滞による解除） |[[商法第527条]]<br>（買主による目的物の保管及び供託） }} {{stub}} [[category:商法|526]] cjhd96525ti1nd7r3cgl9ayjgnwt4d4 0 14056 205917 205090 2022-07-27T22:25:43Z Ef3 694 /* エスケープシーケンス */ \ を前置して文字列中に所望に文字を書く方法をエスケープシーケンス( escape sequence )といい、エスケープシーケンスに前置する文字 ' をエスケープ文字( escape character )といいます。 wikitext text/x-wiki {{Pathnav|メインページ|工学|情報技術|プログラミング|frame=1}} {{Wikipedia|Python}}{{wikiversity|Python}}[[File:Python-logo-notext.svg|thumb|100px|Python]] '''''Python'''''は高水準な汎用プログラミング言語です。 Pythonの設計思想は、コードの読みやすさを重視しています。 たとえばブロックは波括弧 { } ではなくインデントで構造化されているなど、その構造に対するアプローチは独特です。 また、Pythonは、オブジェクト指向・インタープリタ型・動的かたづけ・クロスプラットフォームなプログラミング言語です。 これらのアプローチは、プログラマーが小規模および大規模なプロジェクトで自己説明的で論理的なコードを書けるようにすることを目的としています。 == 目次 == * [[/基本事項|基本事項]]{{---}}[[/基本事項#pythonの実行方法|pythonの実行方法]]、[[/基本事項#「Hello, world!」と表示させよう|Hello, world!]] * [[/変数と代入|変数と代入]]{{---}}[[/変数と代入#変数とは|変数とは]]、[[/変数と代入#代入|代入]]、[[/変数と代入#識別子|識別子]] * [[/数値入力と文字入力と出力表示|数値入力と文字入力と出力表示]]{{---}}input(), int(), float() * [[/条件分岐と繰り返し|条件分岐と繰り返し]]{{---}}if, else, for, while * [[/演算子|演算子]]{{---}} * [[/関数|関数]]{{---}}def、[[/関数#引数のある関数|引数]]、ローカル変数、id()、戻り値、[[/関数#キーワード引数|キーワード引数]]、[[/関数#デコレータ|デコレーター]] * [[/シーケンス|シーケンス]] ** [[/リスト|リスト]]{{---}}''list'' ミュータブルなシーケンスオブジェクト ** [[/タプル|タプル]]{{---}}''tuple'' イミュータブルなシーケンスオブジェクト ** [[/レンジ|レンジ]]{{---}}''range'' 範囲オブジェクト ** [[/array|array]]{{---}}''array'' 要素の型を統一した配列オブジェクト * [[/辞書|辞書]] * [[/セット|セット]] * [[/モジュールのインポート|モジュールのインポート]]{{---}}math モジュール, random モジュール, * [[/例外処理|例外処理]]{{---}}try, except, finally, 複数の例外の場合分け * [[/クラス|クラス]]{{---}}クラス定義, __init__() , self , * [[/型ヒント|型ヒント]]{{---}}[[/型ヒント#型アノテーション|型アノテーション]] * [[/ファイルの書き込みと読み込み|ファイルの書き込みと読み込み]]{{---}}※ open関数, with文を使ったリソース管理、オープンモード、write, readline, === リファレンス === * [[/組込み関数|組込み関数]] * [[/組込み型|組込み型]] == 整理作業中 == * [[Python/整理中]] (複素数、正規表現、HTTPクライアント、JSON、pass) === 内包表記とジェネレータ式 === Pythonには、シーケンスの内包表記とジェネレータ式があります。 ;[https://paiza.io/projects/zcGKAf9f-uN9V7KQrpv4SQ?language=python3 内包表記とジェネレータ式]:<syntaxhighlight lang="python"> for label, expr in {"加算":"1 + 1", "リスト内包表記":"[2 ** x for x in range(5)]", "集合内包表記":"{2 ** x for x in range(5)}", "辞書内包表記":"{x: 2 ** x for x in range(5)}", "ジェネレータ式":"(2 ** x for x in range(5))", "タプルコンストラクターにジェネレータ式を適用":"tuple(2 ** x for x in range(5))", }.items() : print(f'''{label}： {expr} ⇒ {eval(expr)} : {type(eval(expr))}''') </syntaxhighlight> ;実行結果:<syntaxhighlight lang=text> 加算： 1 + 1 ⇒ 2 : <class 'int'> リスト内包表記： [2 ** x for x in range(5)] ⇒ [1, 2, 4, 8, 16] : <class 'list'> 集合内包表記： {2 ** x for x in range(5)} ⇒ {1, 2, 4, 8, 16} : <class 'set'> 辞書内包表記： {x: 2 ** x for x in range(5)} ⇒ {0: 1, 1: 2, 2: 4, 3: 8, 4: 16} : <class 'dict'> ジェネレータ式： (2 ** x for x in range(5)) ⇒ <generator object <genexpr> at 0x14ac1a9e56d0> : <class 'generator'> タプルコンストラクターにジェネレータ式を適用： tuple(2 ** x for x in range(5)) ⇒ (1, 2, 4, 8, 16) : <class 'tuple'> </syntaxhighlight> : Pythonの式を表す文字列（Ex. "1 + 1"）を要素としたタプルをループ変数exprで回しています。 : <code> print(f'{label}：\n {expr}\n ⇒ {eval(expr)} : {type(eval(expr))}')</code>は、 ::<syntaxhighlight lang=text> ラベル： 式 ⇒ 式の評価結果 : 式の評価結果の型 </syntaxhighlight>を表示します。 : <code>(2 ** x for x in range(5))</code>は、タプル内包表記…ではなく、'''ジェネレータ式'''で未評価のシーケンス（generator）を返します（組込み関数のrange同様、この時点ではメモリーオブジェクトではありません）。 : タプルのコンストラクターにジェネレータ式を渡すと、タプルが返ります（タプルはイミュータブルですがメモリーオブジェクトです）。 === 代入演算子 === if文やwhile文の条件には式が要求されるので代入文 <code>=</code> は使えませんでした。 しかし、条件式の中で代入を行うのがふさわしいケースもあります。 このため Python 3.8で、条件式中でもつかえる代入演算子(''Assignment Expressions'') <code>:=</code> （俗称：セイウチ演算子;''Walrus operator''）が導入されました<ref>{{Cite web |title=PEP 572 -- Assignment Expressions |url=https://www.python.org/dev/peps/pep-0572/ |date=2018/02/28 |accessdate=2021/11/12 }}</ref>。 ;[https://paiza.io/projects/WZAGYZS0LP5H1o3XpD4vnw?language=python3 代入演算子の使用例]:<syntaxhighlight lang="python"> a = "1234567" # 7文字 if (n := len(a)) > 5: print("文字が5文字より多いです" , n - 5, "文字オーバー") print(f"あなたは{n} 文字を入力しました") </syntaxhighlight> ;実行結果:<syntaxhighlight lang=text> 文字が5文字より多いです 2 文字オーバー あなたは7 文字を入力しました </syntaxhighlight> 代入演算子を使った条件式を含む文のブロックの外に出ても、そのまま代入した効果は残ります。 なお、<code>f"あなたは{n} 文字を入力しました"</code>はテンプレート・リテラルです。 {{See|[[/数値入力と文字入力と出力表示#テンプレート・リテラル]]}} === エスケープシーケンス === たとえばprint()関数で、「こんにちは」と表示させたい場合なら :<syntaxhighlight lang=pythin3> print("こんにちは") </syntaxhighlight> と書きました。 では、'''"''' を含んだ文字列を表示するにはどうしたら良いでしょう？ やり方は、いくつかあります。 ; " を含んだ文字列を表示する方法:<syntaxhighlight lang="python" line> print('"') print("\"") print("\42") print("\x22") </syntaxhighlight> # クオート文字を ' に変えました。素朴ですがパワフルな方法です。 #: しかし、この方法では " と ' は１つの文字列の中で共存できません。 # " の前に \ を前置すると文字列を閉じる " を打消すことができます。 #: \ は、￥（円記号）の半角で表示されるかもしれませんが、文字コードと機能は同じです。 # \ に続けて " の文字コードを8進数で表記します。 #: 10進数ではないので注意してください。 # \ に続けて x それに続けて文字コードを16進数で表記します。 2. から 4. の様に、 \ を前置して文字列中に所望に文字を書く方法を'''エスケープシーケンス'''( ''escape sequence'' )といい、エスケープシーケンスに前置する文字 ' をエスケープ文字( ''escape character'' )といいます。 === エスケープシーケンスの一覧 === {| class="wikitable" |+ エスケープシーケンスの一覧 ! エスケープシーケンス !! 意味 |- ! \<改行> |バックスラッシュと改行を無視 |- ! \\ |バックスラッシュ自身 (<code>\</code>) |- ! \' |シングルクォーテーション (<code>'</code>) |- ! \" |ダブルクオーテーション (<code>"</code>) |- ! \a |ASCII ベ (BEL) |- ! \b |ASCII バックスペース (BS) |- ! \f |ASCII フォームフィード (FF) |- ! \n |ASCII ラインフィード (LF) |- ! \r |ASCII キャリッジリターン (CR) |- ! \t |ASCII 水平タブ (TAB) |- ! \v |ASCII 垂直タブ (VT) |- ! \ooo | 8進数キャラクタコードによる文字指定 ''ooo'' |- ! \xhh | 16進数キャラクタコードによる文字指定 ''hh'' |} === print関数 === <syntaxhighlight lang="python"> # 「ようこそ」 と出力 print("ようこそ") </syntaxhighlight> <nowiki>#</nowiki>から行末まではコメントです。文字列の出力は<code>print()</code>を使います。Python 2までは<code>print</code>は文でしたが、Python 3では[[Python/組込み関数#print|組込み関数print]]となったため、かっこが必須となります。 文字列は<code>" "</code>で囲んでも<code><nowiki>' '</nowiki></code>で囲んでも同じ意味であり、エスケープ文字の取り扱いに違いはありません。 === 備考 === * インデントについて Pythonのブロックはスペース4つのインデントによって表されます(オフサイドルールといいます)。 * pythonについて pythonは、Googleなどの企業のみならず、MITの初年度のプログラミングの授業でも採用されています。英語圏では[[Ruby]]や[[Perl]]よりも普及しています。 Pythonは1990年にグイド・ヴァンロッサムによって作られました。誰が書いても同じソースコードになるように(違う目的のコードは違う見た目になるように)設計されており、常に読みやすいプログラムを書くことができます。教育用プログラミング言語としても秀逸です。 == 文字列の書式化 == Pythonには、いくつかの異なる文字列の書式化の方法があります。 === 書式化付き文字列化 === C言語の<code>sprintf()</code>に相当する書式付き文字列化は、Pythonでは文字列の % 演算子を使います。 また、書式化文字列に % によるフィールドが複数ある場合は、下のようにタプルを使います。 >>> print("%d.%d.%d" % (2, 6, 4)) 2.6.4 === 文字列の format メソッド === 文字列の format メソッドを使う方法<ref>[https://peps.python.org/pep-3101/ PEP-3101]</ref>。 >>> print("{} {} {}".format(2, 6, 4)) 2.6.4 === f文字列 === PEP 498で新しく f文字列 が追加されました<ref>[https://peps.python.org/pep-498/ PEP-498]</ref>。 >>> print(f"{4} {9} {8}") 4 9 8 ;文字列の書式化:<syntaxhighlight lang=python> print("%d %d %d" % (0!=0, 0==0, 999)) print("{} {} {}".format(0!=0, 0==0, 999)) print(f"{0!=0} {0==0} {999}") print(f"{abs(-123)} {2**10} {999}") </syntaxhighlight> ;実行結果:<syntaxhighlight lang=text> 0 1 999 False True 999 False True 999 123 1024 999 </syntaxhighlight> == pip == pipはPythonのパッケージインストーラーです<ref>{{Cite web |url=https://pip.pypa.io/en/stable/ |title=pip documentation v21.3.1 |date=2021/12/20 accessdate=2021/12/20 }} </ref>。Python Package Index<ref>{{Cite web |url=https://pypi.org/ |title=The Python Package Index (PyPI) is a repository of software for the Python programming language. |date=2021/12/20 accessdate=2021/12/20 }} </ref> などのインデックスからパッケージをインストールするのに使用します。 pipがインストールされているかは、（インターラクティブ・モードではなく）コマンドラインから確認します。 ;FreeBSD:<syntaxhighlight lang="shell"> % uname FreeBSD % pip -V pip 22.1 from /usr/local/lib/python3.10/site-packages/pip (python 3.10) </syntaxhighlight> ;Windows 10:<syntaxhighlight lang="powershell"> PS C:\Users\user1> pip.exe -V pip 21.2.4 from C:\Program Files\WindowsApps\PythonSoftwareFoundation.Python.3.9_3.9.2544.0_x64__qbz5n2kfra8p0\lib\site-packages\pip (python 3.9) </syntaxhighlight> ;GNU/Linux:<syntaxhighlight lang="bash"> $ uname -a Linux localhost 4.14.275-19064-g577a877aa35d #1 SMP PREEMPT Wed May 25 19:32:47 PDT 2022 x86_64 Intel(R) Celeron(R) N4020 CPU @ 1.10GHz GenuineIntel GNU/Linux $ pip -V pip 21.3.1 from /usr/local/lib/python3.10/site-packages/pip (python 3.10) </syntaxhighlight> == YAML == [[W:YAML|YAML]]は、構造化データやオブジェクトを文字列にシリアライズするためのデータ形式の一種です。 Pythonは、初期状態ではYAMLを利用できませんが、pyYaml <ref>https://github.com/yaml/pyyaml</ref>をインストールすることで、pythonでYAMLを処理できるようになります。 pipがインストール済みならば、 ;コマンドライン:<syntaxhighlight lang="shell"> % sudo pip install pyyaml </syntaxhighlight> で pyYaml をインストールできます。 YAMLとPythonは別個の出自なのですが、YAMLはデータ構造をインデントで表し<ref>インデントでデータ構造を表すスタイルをブロックスタイルと呼びます。YAMLには他にフロースタイルと言う形式があり、これはYAML1.2からはJSONそのものです。[https://yaml.org/spec/1.2.2/ YAML Ain’t Markup Language (YAML™) version 1.2]</ref>、Pythonはプログラム構造をインデントをあらわすので似通った外観になります。 === YAMLファイルの読出し === ;test.yaml <syntaxhighlight lang="yaml"> 名前: 姓: 山田 名: 太郎 国籍: 日本 性別: 男 部活: 野球部 </syntaxhighlight> ;[https://paiza.io/projects/2WBoOy3Bw4tO5T22GxBPgA?language=python3 test-yaml.py]:<syntaxhighlight lang="python"> import yaml with open('/workspace/test.yaml') as f: obj = yaml.safe_load(f) print(f"""\ {obj=} {obj["国籍"]=} {obj["名前"]["姓"]=} """) </syntaxhighlight> ;実行結果:<syntaxhighlight lang="python"> obj={'名前': {'姓': '山田', '名': '太郎'}, '国籍': '日本', '性別': '男', '部活': '野球部'} obj["国籍"]='日本' obj["名前"]["姓"]='山田' </syntaxhighlight> : import で yaml をインポートする必要があります。 : pythonでYAMLのセミコロンのデータを読取った場合の辞書型のオブジェクトを返します かつてYAMLの読取りには、yaml.load()が使われていましたが、セキュリティ上の懸念から deprecated となり、yaml.load() を使うと Main.py:4: YAMLLoadWarning: calling yaml.load() without Loader=... is deprecated, as the default Loader is unsafe. Please read https://msg.pyyaml.org/load for full details. と警告されます。yaml.safe_load() を使いましょう。 {{See also|Python/ファイルの書き込みと読み込み#ファイルからの読込み}} === オブジェクトのYAMLへの変換 === ;[https://paiza.io/projects/FXG1RvgSwy6InZ5_9su_RQ?language=python3 コード例]:<syntaxhighlight lang="python"> import yaml obj = { "a": [2,3,5,7], "b": 3.14, "c": "test test", } s = yaml.dump(obj) print("*** Block style ***") print(s); print("*** Load ***") print(yaml.safe_load(s)) s = yaml.dump(obj, default_flow_style=True) print("*** Flow style ***") print(s); </syntaxhighlight> ;実行結果:<syntaxhighlight lang="python"> *** Block style *** a: - 2 - 3 - 5 - 7 b: 3.14 c: test test *** Load *** {'a': [2, 3, 5, 7], 'b': 3.14, 'c': 'test test'} *** Flow style *** {a: [2, 3, 5, 7], b: 3.14, c: test test} </syntaxhighlight> === YAMLファイルの書込み === ;[https://paiza.io/projects/8h3tTkDUlddNCW87LwvHIg?language=python3 コード例]:<syntaxhighlight lang="python"> import yaml obj = { "a": [2,3,5,7], "b": 3.14, "c": "test test", } with open('/workspace/test.yaml', "w") as f: yaml.dump(obj, f) with open('/workspace/test.yaml') as f: for s in f: print(s, end='') print("-"*40) with open('/workspace/test.yaml') as f: print(yaml.safe_load(f)) </syntaxhighlight> ;実行結果:<syntaxhighlight lang="python"> a: - 2 - 3 - 5 - 7 b: 3.14 c: test test ---------------------------------------- {'a': [2, 3, 5, 7], 'b': 3.14, 'c': 'test test'} </syntaxhighlight> {{See also|Python/ファイルの書き込みと読み込み}} == pickle と marshal == pickleモジュールは、Pythonのオブジェクト構造をシリアル化およびデシリアル化するためのバイナリプロトコルを実装しています<ref>{{Cite web |url=https://docs.python.org/3/library/pickle.html |title= 3.10.0 Documentation » The Python Standard Library » Data Persistence » pickle — Python object serialization |date=2021/12/02 |accessdate=2021/12/02 }}</ref>。 marshalモジュールも、Pythonのオブジェクト構造をシリアル化およびデシリアル化するためのバイナリプロトコルの実装ですが、将来に渡ってフォーマットを変えないことは保証されていないので、その用途にはpickleモジュールあるいはshelveモジュールを使ってください<ref>{{Cite web |url=https://docs.python.org/3/library/marshal.html |title= 3.10.0 Documentation » The Python Standard Library » Data Persistence » marshal — Internal Python object serialization |date=2021/12/02 |accessdate=2021/12/02 }}</ref>。 marshalモジュールは、主に.pycファイルのPythonモジュールの "擬似コンパイル "コードの読み書きをサポートするために存在します。 ;[https://paiza.io/projects/wg95etA69kFU0hJovyQm8Q?language=python3 コード例]:<syntaxhighlight lang="python"> import pickle obj = [1,3,5,7] obj.append(obj) print(f'{obj=}') pkl = pickle.dumps(obj) print(f'{pkl=}') print(f'{pickle.loads(pkl)=}') import marshal msl = marshal.dumps(obj) print(f'{msl=}') print(f'{marshal.loads(msl)=}') </syntaxhighlight> ;実行結果:<syntaxhighlight lang="python"> obj=[1, 3, 5, 7, [...]] pkl=b'\x80\x04\x95\x0f\x00\x00\x00\x00\x00\x00\x00]\x94(K\x01K\x03K\x05K\x07h\x00e.' pickle.loads(pkl)=[1, 3, 5, 7, [...]] msl=b'\xdb\x05\x00\x00\x00\xe9\x01\x00\x00\x00\xe9\x03\x00\x00\x00\xe9\x05\x00\x00\x00\xe9\x07\x00\x00\x00r\x00\x00\x00\x00' marshal.loads(msl)=[1, 3, 5, 7, [...]] </syntaxhighlight> == shelve == shelveモジュールは、永続的な辞書の実装です<ref>{{Cite web |url=https://docs.python.org/3/library/shelve.html |title= 3.10.0 Documentation » The Python Standard Library » Data Persistence » shelve — Python object persistence |date=2021/12/02 |accessdate=2021/12/02 }}</ref>。 ;[https://paiza.io/projects/wg95etA69kFU0hJovyQm8Q?language=python3 コード例]:<syntaxhighlight lang="python"> import shelve filename = "/workspace/temp.shelve" with shelve.open(filename) as sh: sh['x'] = 1 sh['y'] = "abc" sh['z'] = [0, 1, 2] print(f'{sh["z"]=}') with shelve.open(filename) as sh: print(f'{ {k:v for k,v in sh.items()}=}') </syntaxhighlight> ;実行結果:<syntaxhighlight lang="python"> sh["z"]=[0, 1, 2] {k:v for k,v in sh.items()}={'z': [0, 1, 2], 'x': 1, 'y': 'abc'} </syntaxhighlight> == 脚註 == <references /> {{stub}} [[Category:Python]] [[Category:プログラミング言語]] {{NDC|007.64}} ko4p8rhsevq8689jsh4o29dudbveid5 205918 205917 2022-07-27T22:35:50Z Ef3 694 /* エスケープシーケンスの一覧 */ wikitext text/x-wiki {{Pathnav|メインページ|工学|情報技術|プログラミング|frame=1}} {{Wikipedia|Python}}{{wikiversity|Python}}[[File:Python-logo-notext.svg|thumb|100px|Python]] '''''Python'''''は高水準な汎用プログラミング言語です。 Pythonの設計思想は、コードの読みやすさを重視しています。 たとえばブロックは波括弧 { } ではなくインデントで構造化されているなど、その構造に対するアプローチは独特です。 また、Pythonは、オブジェクト指向・インタープリタ型・動的かたづけ・クロスプラットフォームなプログラミング言語です。 これらのアプローチは、プログラマーが小規模および大規模なプロジェクトで自己説明的で論理的なコードを書けるようにすることを目的としています。 == 目次 == * [[/基本事項|基本事項]]{{---}}[[/基本事項#pythonの実行方法|pythonの実行方法]]、[[/基本事項#「Hello, world!」と表示させよう|Hello, world!]] * [[/変数と代入|変数と代入]]{{---}}[[/変数と代入#変数とは|変数とは]]、[[/変数と代入#代入|代入]]、[[/変数と代入#識別子|識別子]] * [[/数値入力と文字入力と出力表示|数値入力と文字入力と出力表示]]{{---}}input(), int(), float() * [[/条件分岐と繰り返し|条件分岐と繰り返し]]{{---}}if, else, for, while * [[/演算子|演算子]]{{---}} * [[/関数|関数]]{{---}}def、[[/関数#引数のある関数|引数]]、ローカル変数、id()、戻り値、[[/関数#キーワード引数|キーワード引数]]、[[/関数#デコレータ|デコレーター]] * [[/シーケンス|シーケンス]] ** [[/リスト|リスト]]{{---}}''list'' ミュータブルなシーケンスオブジェクト ** [[/タプル|タプル]]{{---}}''tuple'' イミュータブルなシーケンスオブジェクト ** [[/レンジ|レンジ]]{{---}}''range'' 範囲オブジェクト ** [[/array|array]]{{---}}''array'' 要素の型を統一した配列オブジェクト * [[/辞書|辞書]] * [[/セット|セット]] * [[/モジュールのインポート|モジュールのインポート]]{{---}}math モジュール, random モジュール, * [[/例外処理|例外処理]]{{---}}try, except, finally, 複数の例外の場合分け * [[/クラス|クラス]]{{---}}クラス定義, __init__() , self , * [[/型ヒント|型ヒント]]{{---}}[[/型ヒント#型アノテーション|型アノテーション]] * [[/ファイルの書き込みと読み込み|ファイルの書き込みと読み込み]]{{---}}※ open関数, with文を使ったリソース管理、オープンモード、write, readline, === リファレンス === * [[/組込み関数|組込み関数]] * [[/組込み型|組込み型]] == 整理作業中 == * [[Python/整理中]] (複素数、正規表現、HTTPクライアント、JSON、pass) === 内包表記とジェネレータ式 === Pythonには、シーケンスの内包表記とジェネレータ式があります。 ;[https://paiza.io/projects/zcGKAf9f-uN9V7KQrpv4SQ?language=python3 内包表記とジェネレータ式]:<syntaxhighlight lang="python"> for label, expr in {"加算":"1 + 1", "リスト内包表記":"[2 ** x for x in range(5)]", "集合内包表記":"{2 ** x for x in range(5)}", "辞書内包表記":"{x: 2 ** x for x in range(5)}", "ジェネレータ式":"(2 ** x for x in range(5))", "タプルコンストラクターにジェネレータ式を適用":"tuple(2 ** x for x in range(5))", }.items() : print(f'''{label}： {expr} ⇒ {eval(expr)} : {type(eval(expr))}''') </syntaxhighlight> ;実行結果:<syntaxhighlight lang=text> 加算： 1 + 1 ⇒ 2 : <class 'int'> リスト内包表記： [2 ** x for x in range(5)] ⇒ [1, 2, 4, 8, 16] : <class 'list'> 集合内包表記： {2 ** x for x in range(5)} ⇒ {1, 2, 4, 8, 16} : <class 'set'> 辞書内包表記： {x: 2 ** x for x in range(5)} ⇒ {0: 1, 1: 2, 2: 4, 3: 8, 4: 16} : <class 'dict'> ジェネレータ式： (2 ** x for x in range(5)) ⇒ <generator object <genexpr> at 0x14ac1a9e56d0> : <class 'generator'> タプルコンストラクターにジェネレータ式を適用： tuple(2 ** x for x in range(5)) ⇒ (1, 2, 4, 8, 16) : <class 'tuple'> </syntaxhighlight> : Pythonの式を表す文字列（Ex. "1 + 1"）を要素としたタプルをループ変数exprで回しています。 : <code> print(f'{label}：\n {expr}\n ⇒ {eval(expr)} : {type(eval(expr))}')</code>は、 ::<syntaxhighlight lang=text> ラベル： 式 ⇒ 式の評価結果 : 式の評価結果の型 </syntaxhighlight>を表示します。 : <code>(2 ** x for x in range(5))</code>は、タプル内包表記…ではなく、'''ジェネレータ式'''で未評価のシーケンス（generator）を返します（組込み関数のrange同様、この時点ではメモリーオブジェクトではありません）。 : タプルのコンストラクターにジェネレータ式を渡すと、タプルが返ります（タプルはイミュータブルですがメモリーオブジェクトです）。 === 代入演算子 === if文やwhile文の条件には式が要求されるので代入文 <code>=</code> は使えませんでした。 しかし、条件式の中で代入を行うのがふさわしいケースもあります。 このため Python 3.8で、条件式中でもつかえる代入演算子(''Assignment Expressions'') <code>:=</code> （俗称：セイウチ演算子;''Walrus operator''）が導入されました<ref>{{Cite web |title=PEP 572 -- Assignment Expressions |url=https://www.python.org/dev/peps/pep-0572/ |date=2018/02/28 |accessdate=2021/11/12 }}</ref>。 ;[https://paiza.io/projects/WZAGYZS0LP5H1o3XpD4vnw?language=python3 代入演算子の使用例]:<syntaxhighlight lang="python"> a = "1234567" # 7文字 if (n := len(a)) > 5: print("文字が5文字より多いです" , n - 5, "文字オーバー") print(f"あなたは{n} 文字を入力しました") </syntaxhighlight> ;実行結果:<syntaxhighlight lang=text> 文字が5文字より多いです 2 文字オーバー あなたは7 文字を入力しました </syntaxhighlight> 代入演算子を使った条件式を含む文のブロックの外に出ても、そのまま代入した効果は残ります。 なお、<code>f"あなたは{n} 文字を入力しました"</code>はテンプレート・リテラルです。 {{See|[[/数値入力と文字入力と出力表示#テンプレート・リテラル]]}} === エスケープシーケンス === たとえばprint()関数で、「こんにちは」と表示させたい場合なら :<syntaxhighlight lang=pythin3> print("こんにちは") </syntaxhighlight> と書きました。 では、'''"''' を含んだ文字列を表示するにはどうしたら良いでしょう？ やり方は、いくつかあります。 ; " を含んだ文字列を表示する方法:<syntaxhighlight lang="python" line> print('"') print("\"") print("\42") print("\x22") </syntaxhighlight> # クオート文字を ' に変えました。素朴ですがパワフルな方法です。 #: しかし、この方法では " と ' は１つの文字列の中で共存できません。 # " の前に \ を前置すると文字列を閉じる " を打消すことができます。 #: \ は、￥（円記号）の半角で表示されるかもしれませんが、文字コードと機能は同じです。 # \ に続けて " の文字コードを8進数で表記します。 #: 10進数ではないので注意してください。 # \ に続けて x それに続けて文字コードを16進数で表記します。 2. から 4. の様に、 \ を前置して文字列中に所望に文字を書く方法を'''エスケープシーケンス'''( ''escape sequence'' )といい、エスケープシーケンスに前置する文字 ' をエスケープ文字( ''escape character'' )といいます。 === エスケープシーケンスの一覧 === :{| class="wikitable" |+ エスケープシーケンスの一覧 ! エスケープシーケンス !! 意味 |- ! \<改行> |バックスラッシュと改行を無視 |- ! \\ |バックスラッシュ自身 (<code>\</code>) |- ! \' |シングルクォーテーション (<code>'</code>) |- ! \" |ダブルクオーテーション (<code>"</code>) |- ! \a |ASCII ベル（アラート） (BEL) |- ! \b |ASCII バックスペース (BS) |- ! \f |ASCII フォームフィード (FF) |- ! \n |ASCII ラインフィード (LF) |- ! \r |ASCII キャリッジリターン (CR) |- ! \t |ASCII 水平タブ (TAB) |- ! \v |ASCII 垂直タブ (VT) |- ! \ooo | 8進数キャラクタコードによる文字指定 ''ooo'' |- ! \xhh | 16進数キャラクタコードによる文字指定 ''hh'' |- ! \uxxxx | 16ビットの16進数値xxxxを持つUnicode文字 |- ! \Uxxxxxxxx | 32ビットの16進数値xxxxxxxxを持つUnicode文字 |} === print関数 === <syntaxhighlight lang="python"> # 「ようこそ」 と出力 print("ようこそ") </syntaxhighlight> <nowiki>#</nowiki>から行末まではコメントです。文字列の出力は<code>print()</code>を使います。Python 2までは<code>print</code>は文でしたが、Python 3では[[Python/組込み関数#print|組込み関数print]]となったため、かっこが必須となります。 文字列は<code>" "</code>で囲んでも<code><nowiki>' '</nowiki></code>で囲んでも同じ意味であり、エスケープ文字の取り扱いに違いはありません。 === 備考 === * インデントについて Pythonのブロックはスペース4つのインデントによって表されます(オフサイドルールといいます)。 * pythonについて pythonは、Googleなどの企業のみならず、MITの初年度のプログラミングの授業でも採用されています。英語圏では[[Ruby]]や[[Perl]]よりも普及しています。 Pythonは1990年にグイド・ヴァンロッサムによって作られました。誰が書いても同じソースコードになるように(違う目的のコードは違う見た目になるように)設計されており、常に読みやすいプログラムを書くことができます。教育用プログラミング言語としても秀逸です。 == 文字列の書式化 == Pythonには、いくつかの異なる文字列の書式化の方法があります。 === 書式化付き文字列化 === C言語の<code>sprintf()</code>に相当する書式付き文字列化は、Pythonでは文字列の % 演算子を使います。 また、書式化文字列に % によるフィールドが複数ある場合は、下のようにタプルを使います。 >>> print("%d.%d.%d" % (2, 6, 4)) 2.6.4 === 文字列の format メソッド === 文字列の format メソッドを使う方法<ref>[https://peps.python.org/pep-3101/ PEP-3101]</ref>。 >>> print("{} {} {}".format(2, 6, 4)) 2.6.4 === f文字列 === PEP 498で新しく f文字列 が追加されました<ref>[https://peps.python.org/pep-498/ PEP-498]</ref>。 >>> print(f"{4} {9} {8}") 4 9 8 ;文字列の書式化:<syntaxhighlight lang=python> print("%d %d %d" % (0!=0, 0==0, 999)) print("{} {} {}".format(0!=0, 0==0, 999)) print(f"{0!=0} {0==0} {999}") print(f"{abs(-123)} {2**10} {999}") </syntaxhighlight> ;実行結果:<syntaxhighlight lang=text> 0 1 999 False True 999 False True 999 123 1024 999 </syntaxhighlight> == pip == pipはPythonのパッケージインストーラーです<ref>{{Cite web |url=https://pip.pypa.io/en/stable/ |title=pip documentation v21.3.1 |date=2021/12/20 accessdate=2021/12/20 }} </ref>。Python Package Index<ref>{{Cite web |url=https://pypi.org/ |title=The Python Package Index (PyPI) is a repository of software for the Python programming language. |date=2021/12/20 accessdate=2021/12/20 }} </ref> などのインデックスからパッケージをインストールするのに使用します。 pipがインストールされているかは、（インターラクティブ・モードではなく）コマンドラインから確認します。 ;FreeBSD:<syntaxhighlight lang="shell"> % uname FreeBSD % pip -V pip 22.1 from /usr/local/lib/python3.10/site-packages/pip (python 3.10) </syntaxhighlight> ;Windows 10:<syntaxhighlight lang="powershell"> PS C:\Users\user1> pip.exe -V pip 21.2.4 from C:\Program Files\WindowsApps\PythonSoftwareFoundation.Python.3.9_3.9.2544.0_x64__qbz5n2kfra8p0\lib\site-packages\pip (python 3.9) </syntaxhighlight> ;GNU/Linux:<syntaxhighlight lang="bash"> $ uname -a Linux localhost 4.14.275-19064-g577a877aa35d #1 SMP PREEMPT Wed May 25 19:32:47 PDT 2022 x86_64 Intel(R) Celeron(R) N4020 CPU @ 1.10GHz GenuineIntel GNU/Linux $ pip -V pip 21.3.1 from /usr/local/lib/python3.10/site-packages/pip (python 3.10) </syntaxhighlight> == YAML == [[W:YAML|YAML]]は、構造化データやオブジェクトを文字列にシリアライズするためのデータ形式の一種です。 Pythonは、初期状態ではYAMLを利用できませんが、pyYaml <ref>https://github.com/yaml/pyyaml</ref>をインストールすることで、pythonでYAMLを処理できるようになります。 pipがインストール済みならば、 ;コマンドライン:<syntaxhighlight lang="shell"> % sudo pip install pyyaml </syntaxhighlight> で pyYaml をインストールできます。 YAMLとPythonは別個の出自なのですが、YAMLはデータ構造をインデントで表し<ref>インデントでデータ構造を表すスタイルをブロックスタイルと呼びます。YAMLには他にフロースタイルと言う形式があり、これはYAML1.2からはJSONそのものです。[https://yaml.org/spec/1.2.2/ YAML Ain’t Markup Language (YAML™) version 1.2]</ref>、Pythonはプログラム構造をインデントをあらわすので似通った外観になります。 === YAMLファイルの読出し === ;test.yaml <syntaxhighlight lang="yaml"> 名前: 姓: 山田 名: 太郎 国籍: 日本 性別: 男 部活: 野球部 </syntaxhighlight> ;[https://paiza.io/projects/2WBoOy3Bw4tO5T22GxBPgA?language=python3 test-yaml.py]:<syntaxhighlight lang="python"> import yaml with open('/workspace/test.yaml') as f: obj = yaml.safe_load(f) print(f"""\ {obj=} {obj["国籍"]=} {obj["名前"]["姓"]=} """) </syntaxhighlight> ;実行結果:<syntaxhighlight lang="python"> obj={'名前': {'姓': '山田', '名': '太郎'}, '国籍': '日本', '性別': '男', '部活': '野球部'} obj["国籍"]='日本' obj["名前"]["姓"]='山田' </syntaxhighlight> : import で yaml をインポートする必要があります。 : pythonでYAMLのセミコロンのデータを読取った場合の辞書型のオブジェクトを返します かつてYAMLの読取りには、yaml.load()が使われていましたが、セキュリティ上の懸念から deprecated となり、yaml.load() を使うと Main.py:4: YAMLLoadWarning: calling yaml.load() without Loader=... is deprecated, as the default Loader is unsafe. Please read https://msg.pyyaml.org/load for full details. と警告されます。yaml.safe_load() を使いましょう。 {{See also|Python/ファイルの書き込みと読み込み#ファイルからの読込み}} === オブジェクトのYAMLへの変換 === ;[https://paiza.io/projects/FXG1RvgSwy6InZ5_9su_RQ?language=python3 コード例]:<syntaxhighlight lang="python"> import yaml obj = { "a": [2,3,5,7], "b": 3.14, "c": "test test", } s = yaml.dump(obj) print("*** Block style ***") print(s); print("*** Load ***") print(yaml.safe_load(s)) s = yaml.dump(obj, default_flow_style=True) print("*** Flow style ***") print(s); </syntaxhighlight> ;実行結果:<syntaxhighlight lang="python"> *** Block style *** a: - 2 - 3 - 5 - 7 b: 3.14 c: test test *** Load *** {'a': [2, 3, 5, 7], 'b': 3.14, 'c': 'test test'} *** Flow style *** {a: [2, 3, 5, 7], b: 3.14, c: test test} </syntaxhighlight> === YAMLファイルの書込み === ;[https://paiza.io/projects/8h3tTkDUlddNCW87LwvHIg?language=python3 コード例]:<syntaxhighlight lang="python"> import yaml obj = { "a": [2,3,5,7], "b": 3.14, "c": "test test", } with open('/workspace/test.yaml', "w") as f: yaml.dump(obj, f) with open('/workspace/test.yaml') as f: for s in f: print(s, end='') print("-"*40) with open('/workspace/test.yaml') as f: print(yaml.safe_load(f)) </syntaxhighlight> ;実行結果:<syntaxhighlight lang="python"> a: - 2 - 3 - 5 - 7 b: 3.14 c: test test ---------------------------------------- {'a': [2, 3, 5, 7], 'b': 3.14, 'c': 'test test'} </syntaxhighlight> {{See also|Python/ファイルの書き込みと読み込み}} == pickle と marshal == pickleモジュールは、Pythonのオブジェクト構造をシリアル化およびデシリアル化するためのバイナリプロトコルを実装しています<ref>{{Cite web |url=https://docs.python.org/3/library/pickle.html |title= 3.10.0 Documentation » The Python Standard Library » Data Persistence » pickle — Python object serialization |date=2021/12/02 |accessdate=2021/12/02 }}</ref>。 marshalモジュールも、Pythonのオブジェクト構造をシリアル化およびデシリアル化するためのバイナリプロトコルの実装ですが、将来に渡ってフォーマットを変えないことは保証されていないので、その用途にはpickleモジュールあるいはshelveモジュールを使ってください<ref>{{Cite web |url=https://docs.python.org/3/library/marshal.html |title= 3.10.0 Documentation » The Python Standard Library » Data Persistence » marshal — Internal Python object serialization |date=2021/12/02 |accessdate=2021/12/02 }}</ref>。 marshalモジュールは、主に.pycファイルのPythonモジュールの "擬似コンパイル "コードの読み書きをサポートするために存在します。 ;[https://paiza.io/projects/wg95etA69kFU0hJovyQm8Q?language=python3 コード例]:<syntaxhighlight lang="python"> import pickle obj = [1,3,5,7] obj.append(obj) print(f'{obj=}') pkl = pickle.dumps(obj) print(f'{pkl=}') print(f'{pickle.loads(pkl)=}') import marshal msl = marshal.dumps(obj) print(f'{msl=}') print(f'{marshal.loads(msl)=}') </syntaxhighlight> ;実行結果:<syntaxhighlight lang="python"> obj=[1, 3, 5, 7, [...]] pkl=b'\x80\x04\x95\x0f\x00\x00\x00\x00\x00\x00\x00]\x94(K\x01K\x03K\x05K\x07h\x00e.' pickle.loads(pkl)=[1, 3, 5, 7, [...]] msl=b'\xdb\x05\x00\x00\x00\xe9\x01\x00\x00\x00\xe9\x03\x00\x00\x00\xe9\x05\x00\x00\x00\xe9\x07\x00\x00\x00r\x00\x00\x00\x00' marshal.loads(msl)=[1, 3, 5, 7, [...]] </syntaxhighlight> == shelve == shelveモジュールは、永続的な辞書の実装です<ref>{{Cite web |url=https://docs.python.org/3/library/shelve.html |title= 3.10.0 Documentation » The Python Standard Library » Data Persistence » shelve — Python object persistence |date=2021/12/02 |accessdate=2021/12/02 }}</ref>。 ;[https://paiza.io/projects/wg95etA69kFU0hJovyQm8Q?language=python3 コード例]:<syntaxhighlight lang="python"> import shelve filename = "/workspace/temp.shelve" with shelve.open(filename) as sh: sh['x'] = 1 sh['y'] = "abc" sh['z'] = [0, 1, 2] print(f'{sh["z"]=}') with shelve.open(filename) as sh: print(f'{ {k:v for k,v in sh.items()}=}') </syntaxhighlight> ;実行結果:<syntaxhighlight lang="python"> sh["z"]=[0, 1, 2] {k:v for k,v in sh.items()}={'z': [0, 1, 2], 'x': 1, 'y': 'abc'} </syntaxhighlight> == 脚註 == <references /> {{stub}} [[Category:Python]] [[Category:プログラミング言語]] {{NDC|007.64}} 85iphwofsf2j0lf5m4ts1w4zq08ioq0 0 17362 205923 191766 2022-07-28T07:11:14Z 218.220.56.61 /* 本文 */ wikitext text/x-wiki [[文学]]＞[[古典文学]]＞[[日本の古典]]＞[[平家物語]] [[Category:平家物語|きおんしようしや]] ==本文== [[w:祇園精舍|祇園精舍]]の鐘の声、[[w:諸行無常|諸行無常]]の響きあり。[[w:娑羅双樹|娑羅双樹]]の花の色、盛者必衰の理をあらはす。奢れる人も久しからず、ただ春の夜の夢のごとし。猛き者もつひにはほろびぬ、ひとへに風の前の塵に同じ 遠く[[w:中国の歴史|異朝]]をとぶらへば、[[w:秦|秦]]の[[w:趙高|趙高]]、[[w:漢|漢]]の[[w:王莽|王莽]]、[[w:梁 (南朝) |梁]]の[[w:朱イ|朱忌]]、[[w:唐|唐]]の[[w:安禄山|祿山]]、これらは皆[[w:君主|舊主]][[w:皇帝|先皇]]の[[w:政治|政]]にもしたがはず、樂しみをきはめ、諌めをも思ひ入れず、[[w:天下|天下]]の亂れん事を悟らずして、[[w:民間|民間]]の愁ふるところを知らざつしかば、久しからずして、亡じにし者どもなり。 近く[[w:日本の歴史|本朝]]をうかがふに、[[w:承平(日本)|承平]]の[[w:平将門|將門]]、[[w:天慶|天慶]]の[[w:藤原純友|純友]]、[[w:康和|康和]]の[[w:源義親|義親]]、[[w:平治|平治]]の[[w:藤原信頼|信賴]]、これらはおごれる心もたけき事も、皆とりどりにこそありしかども、まぢかくは[[w:六波羅|六波羅]]の[[w:入道|入道]]、[[w:太政大臣|前太政大臣]][[w:平清盛|平朝臣清盛公]]と申しし人のありさま、傳へ承るこそ心もことばも及ばれね。 その[[w:先祖|先祖]]を尋ぬれば[[w:桓武天皇|桓武天皇]]第五の皇子、[[w:一品|一品]][[w:式部省|式部卿]][[w:葛原親王|葛原親王]]九代の後胤、[[w:讃岐|讃岐守]][[w:平正盛|正盛]]が孫、[[w:刑部省|刑部卿]][[w:平忠盛|忠盛]]朝臣の[[w:嫡男|嫡男]]なり。かの[[w:親王|親王]]の[[w:王 (皇族) |御子]]、[[w:高見王|高見王]]、無官無位にして失せ給ひぬ。その御子、[[w:高望王|高望王]]の時、初めて平の姓を賜はつて、[[w:上総|上総介]]に成り給ひしより、たちまちに王氏を出でて人臣に列なる、その子[[w:鎮守府将軍|鎮守府将軍]][[w:平国香|良望、後]]には[[w:平国香|國香]]と改む。國香より[[w:平正盛|正盛]]に至る六代は、諸国の[[w:受領|受領]]たりしかども、[[w:昇殿|殿上]]の仙籍をば未だ赦されず。 ---- ==本文の読み方== [[w:祇園精舎|ぎおんしょうじゃ]]のかねのこえ、[[w:諸行無常|しょぎょうむじょう]]のひびきあり。 [[w:沙羅双樹|しゃらそうじゅ]]のはなのいろ、 じょうしゃひっすいのことわりをあらわす。 おごれるひともひさしからず、 ただはるのよのゆめのごとし。 たけきものもついにはほろびぬ、 ひとえにかぜのまえのちりにおなじ。 とおく[[w:異朝|いちょう]]をとぶらえば、 しんのちょうこう、かんのおうもう、りょうのしゅうい、とうのろくさん、 これらはみな、きゅうしゅせんこうのまつりごとにもしたがわず、 たのしみをきわめ、いさめをもおもいいれず、 てんかのみだれんことをさとらずして、 みんかんのうれうるところをしらざつしかば、 ひさしからずしてぼうじにしものどもなり。 ちかくほんちょうをうかがうに、 じょうへいのまさかど、てんぎょうのすみとも、こうわのぎしん、へいじののぶより、 これらはおごれるこころも、たけきこともみなとりどりにこそありしかども、まぢかくは、 ろくはらのにゅうどう、さきのだいじょうだいじん、たいらのあそんきよもりこうともうししひとのありさま、 つたえうけたまわるこそ、こころもことばもおよばれね。 そのせんぞをたずぬればかんむてんのうだいごのおうじ、 いっぽんしきぶきょうかずらはらしんのうくだいのこういん、さぬきのかみまさもりがまご、 ぎょうぶきょうただもりのあそんのちゃくなんなり。 かのしんのうのみこ、たかみのおう、むかんむいにしてうせたまいぬ。 そのみこ、たかもちのおうのとき、はじめてへいのしょうをたまわって、 かずさのすけになりたまいしより、たちまちにおうしをいでてじんしんにつらなる。 そのこちんじゅふのしょうぐんよしもち、のちにはくにかとあらたむ。 くにかよりまさもりにいたるまでろくだいは、しょこくのずりょうたりしかども、 てんじょうのせんせきをばいまだゆるされず。 ==現代語訳== [[w:祇園精舍|祇園精舍]]の鐘の音には、[[w:諸行無常|諸行無常]]すなわちこの世のすべての現象は絶えず変化していくものだという響きがある。[[w:娑羅双樹|娑羅双樹]]の花の色は、どんなに勢いが盛んな者も必ず衰えるものであるという道理をあらわしている。世に栄え得意になっている者も、その栄えはずっとは続かず、春の夜の夢のようである。勢い盛んではげしい者も、結局は滅び去り、まるで風に吹き飛ばされる塵と同じようである。 遠い[[w:中国の歴史|外国]] (の例) を見ると、[[w:秦|秦]]の[[w:趙高|趙高]]、[[w:漢|漢]]の[[w:王莽|王莽]]、[[w:梁 (南朝) |梁]]の[[w:朱イ|朱忌]]、[[w:唐|唐]]の[[w:安禄山|安禄山]]、これらはみな元の[[w:君主|君主]]や先代[[w:皇帝|皇帝]]の政治に従わず、(栄華の)楽しみを極め、忠告にも深く考えようとはせず、[[w:天下|天下]]が乱れることもわからずに、人々の苦労するところとなるものも知らなかったので、長続きせずに滅びた者たちである。 身近な[[w:日本の歴史|日本]] (の例) を見ると、[[w:承平 (日本) |承平]]の[[w:平将門|平将門]]、[[w:天慶|天慶]]の[[w:藤原純友|藤原純友]]、[[w:康和|康和]]の[[w:源義親|源義親]]、[[w:平治|平治]]の[[w:藤原信頼|藤原信頼]]、(これらの人は)得意になる心も猛々しい心も、みなそれぞれ持っていたが、最近では[[w:六波羅|六波羅]]の[[w:入道|入道]]、[[w:太政大臣|前太政大臣]][[w:平清盛|平朝臣清盛公]]と申した人の様子は伝え聞いても想像することも形容することもできない(ほどである)。 その清盛の[[w:先祖|先祖]]を調べると、[[w:桓武天皇|桓武天皇]]の第五皇子、一品式部卿葛原親王から数えて九代目の子孫、讃岐守正盛の孫で、刑部卿忠盛の嫡男である。葛原親王の御子、高見王は、官職も官位もないままなくなられた。その御子の高望王のとき、初めて平の姓を賜わって、上総介になられてから、ただちに皇籍を離れて臣下の列に連なる。その子・鎮守府将軍良望は、後には国香と名を改めた国香から正盛に至るまでの六代は、諸国の国守ではあったが、殿上人として昇殿することは、まだ許されなかった。 ---- [[File:平家物語･祇園精舎サンプル3.png|thumb|left|祇園精舎　原文]] [[File:平家物語･祇園精舎 現代語訳.png|thumb|none|祇園精舎　現代語訳]] kxmzpn2mr3a94eteu763l87axfpjsn3 0 20904 205920 92153 2022-07-28T00:01:47Z Ef3 694 /* はじめの一歩 */ Bumpup 7.6.3 to 9.2.3, GHCi を終了するには、:quit (または単に:q)を使う。 wikitext text/x-wiki {{clear}} {{Haskell minitoc|chapter=Haskell Basics|noexercises=1}} 本章の手順にしたがい、必要なプログラムをインストールすることで、Haskellでコーディングを開始できるようになる。 == Haskellのインストール == Haskellは「プログラミング言語」である。つまり、人間がコンピュータに指示を与えるときに使う言語である。 ちょうど、料理のレシピを書くのに似ている。あなたはプログラミング言語をつかってレシピを書き、コンピュータがそれを実行するのである。 Haskellで書かれたプログラムを利用するには、別の特別なプログラムが必要である。それは、Haskell「コンパイラ」と呼ばれるものである。コンパイラは、Haskellで書かれたコードを受け取り、「マシン語」に翻訳する。マシン語というのはより原始的な言語なので、コンピュータが理解することができる。再び料理にたとえて言えば、レシピ（＝Haskellのプログラム）を書くのがあなた。実際に作業するのが、コック（＝Haskellコンパイラ）であり、食材を組み合わせて料理（＝実行可能ファイル）を作る。そう、出された料理からレシピを再現するのは簡単ではない。（同様に、コンパイル後の実行可能ファイルから、Haskellのコードを得ることもできない。） Haskellの学習を始めるため、'''[http://hackage.haskell.org/platform/ Haskell platform]をダウンロードしてインストールしよう。'''platformには「Glasgow Haskellコンパイラ」（略してGHC）のほか、必要なものが全部含まれている。 お試しだったり、あるいは、コンパイラ一式を入れるのがイヤというなら、[http://www.haskell.org/hugs/ Hugs]を使ってみるとよい。Hugsは、軽量の（しかも可搬性に優れた）Haskellインタプリタである。あるいは、[http://www.tryhaskell.org/ TryHaskell]も気にいるかもしれない。TryHaskellは、オンラインですぐ使えるインタプリタである。以降は、すべてGHC向けの手順なので、気をつけてほしい。 {{body note|1= UNIXユーザの皆様へ もしあなたが、ソースからコンパイルするのを好む人だとしても、GHCの場合、賢明な考えとは言えない。初めてインストールする場合、なおさらである。というのも、GHC自体、大部分がHaskellで書かれているので、手作業でブートするのは相当トリッキーな作業となる。さらに、ビルドには「膨大な」時間がかかり、大量のディスク容量も消費してしまう。それでも、どうしても、GHCをソースからビルドしたいというなら、[http://hackage.haskell.org/trac/ghc/wiki/Building Building and Porting GHC at the GHC homepage]を見てほしい。 まとめると、Haskell Platformをダウンロードすることを、強くお薦めする。ソースからコンパイルするのでなく。 }} == はじめの一歩 == [http://hackage.haskell.org/platform/ Haskell Platform]のインストールが済んだら、いよいよ、初めてのHaskellコードを書く時間である。 ここで使うのは、'''GHCi'''というプログラムである。iは対話（interactive）のiである。OSに応じ、以下手順を実行してほしい。 * Windows: スタートメニューのファイル名を指定して実行から「cmd」と入力してEnterキーを押す。続いて<code>ghci</code>と入力して、再度Enterキーを押す。 * MacOS: 「ターミナル」（アプリケーション＞ユーティリティ＞ターミナル）を起動し、現れたウィンドウに<code>ghci</code>と入力してEnterキーを押す。 * Linux: ターミナルを起動し<code>ghci</code>プログラムをrunする。 以下のような出力が得られるはずである。 <syntaxhighlight lang=console> % ghci GHCi, version 9.2.3: https://www.haskell.org/ghc/ :? for help ghci> _ </syntaxhighlight> まず、表示されるのは、GHCiのバージョン情報。次に、<code>ghci&gt;</code>は、いわゆる「プロンプト」と呼ばれるものである。ここにコマンドを入力すると、GHCiが結果を返してくれる。 さあ、これで、初めてのHaskellコードを書く準備が整った。ひとつ、簡単な計算をいくつか試してみよう。 {{HaskellGHCi|1= ghci> 2 + 2 4 ghci> 5 + 4 * 3 17 ghci> 2 ^ 5 32 }} これらの演算子は、他のほとんどのプログラミング言語と一致している。<code>+</code>は加算、<code>*</code>は乗算、<code>^</code>は累乗（<math>a ^ b</math>）に対応する。2番目の例で示したように、Haskellは数学演算の標準的な順序に従う（例えば、加算の前に乗算を行うなど）。 これで、Haskellを電卓として使う方法がわかったと思う。実際、Haskell は常に電卓である。ただ、数字だけでなく、文字、リスト、関数、木、そして他のプログラムといった他のオブジェクトも扱える、とても強力な電卓である（これらの用語にまだ慣れていなくても、いまは心配はいらない）。 GHCi を終了するには、:quit (または単に:q)を使う。 {{HaskellGHCi|1= ghci> :quit Leaving GHCi. % _ }} GHCiは強力な開発環境だ。この章では、ソースコードの入ったファイルを GHCi に読み込ませ、その中の様々な部分を評価（evaluate）する方法を学びる。 もしあなたがここまでのことを理解しているなら（もし理解していないなら、トークページを使ってこのWikibookを改善するのを手伝ってください！）、次の章ではHaskellの基本概念をいくつか紹介し、最初のHaskell関数を作る準備が整っている。 {{Auto category}} {{Haskell/Interlanguage|en|Haskell/Getting set up}} {{Haskell/Interlanguage|pt|Haskell/Instalação e aritmética}} s6ncluf5c7pbsfr331kjde55p0q93k7 0 21996 205925 205562 2022-07-28T07:51:26Z すじにくシチュー 12058 wikitext text/x-wiki <!-- このページには導入部がありません。適切な導入部を作成し、このコメントを除去してください。 --> == 目次 == * [[高校英語の文法/文の種類]] * [[高校英語の文法/動詞と文型]] * [[高校英語の文法/時制]] ※ 参考書によって微妙に単元名が異なるので暫定 * [[高校英語の文法/完了形]] * [[高校英語の文法/助動詞]] * * [[高校英語の文法/比較]] * [[高校英語の文法/関係詞]] * [[高校英語の文法/仮定法]] * [[高校英語の文法/名詞]] * [[高校英語の文法/冠詞]] * * [[高校英語の文法/否定]] * [[高校英語の文法/接続詞]] * [[高校英語の文法/前置詞]] == 文の構造 == === 文の要素 === 文の構造を知るためには、文がどのような要素で成り立っているのかを知らなければならない。 ==== 主語と述語動詞 ==== # '''The old man''' ''is'' a famous singer. # '''My sister''' ''studied'' math. ## 訳例:その老人'''は'''有名な歌手'''だ'''。 ## 訳例:私の姉'''は'''数学を研究'''していた'''。 1の文は「AはBだ」という文であり、2の文は「AはCする」という文である。どちらも # 「…は」「…が」という主題の部分 # 「～である」「～する」という主題が何であるかについて述べる部分 の二つが共通している。 この場合、1を'''主部'''といい、2を'''述部'''という。 そして、主部の中心となる語を'''主語'''(Subject)といい、述部の中心となる部分を'''述語動詞'''(Predicate Verb略して'''動詞'''('''Verb'''))という。以下では、述語動詞は原則として単に動詞と呼ぶ。 {| class="wikitable" style="text-align:center" |- ! || - || 主語 || 述語動詞 || - |- | - | colspan="2" | 主部 | colspan="2" | 述部 |- | 1. | The old | man | is | a famous singer. |- | 2. | My | sister | studied | math. |} 主語は単に'''S'''で表し、動詞は'''V'''で表す。 ==== 目的語 ==== # He ''has'' '''a personal computer'''. # We ''played'' '''soccer'''. # Everone ''likes'' '''Sushi'''. ## 訳例:彼はパソコン'''を'''持っている。 ## 訳例:私たちはサッカー'''を'''した。 ## 訳例:みんなが寿司'''を'''好む。 いずれの文の動詞も「～を」という、動作の対象が必要である。このような動作の対象を表す語を'''目的語'''(Object)といい、'''O'''で表す。 {| class="wikitable" style="text-align:center" |- ! || 主語 || 動詞 || 目的語 |- | - | colspan="1" | 主部 | colspan="2" | 述部 |- | 1. | He | has | a personal computer. |- | 2. | We | played | soccer. |- | 3. | Everone | likes | Sushi. |} このような、'''S+V+O'''という形の文は英文の基本形の一つである。 ==== 補語 ==== # Mary ''is'' '''happy'''. # John ''became'' '''a doctor'''. ## 訳例:メアリーは幸せだ。 ## 訳例:ジョンは医者になった。 これらはいずれも主語の状態を説明した文であるが、isやbecomeで文を切ると意味をとれない。happyやa doctorという、主語の様子をおぎなう語があって初めて意味のある文となる。このように、主語の様子について説明する語を'''補語'''(Complement)という。補語は'''C'''で表される。 {| class="wikitable" style="text-align:center" |- ! || 主語 || 動詞 || 補語 |- | - | colspan="1" | 主部 | colspan="2" | 述部 |- | 1. | Mary | is | happy. |- | 2. | John | became | a doctor. |} このような'''S+V+C'''の文も基本的な文の一つである。なお、後で学ぶように、補語は主語の様子だけでなく目的語の様子を説明する場合もある(例文:I call him Sensei.(私は彼を先生と呼ぶ))。 == 動詞の用法 == === 助動詞 === === 態 === ==== 助動詞と組み合わさった受動態 ==== He could be seen by her. 受動態の文を作るときには、その文の述語は必ずbe動詞の節になるが、be動詞に対して助動詞を用いたり、時制の変化をさせることも普通に行なわれる。 この時には、例えば He is seen by her. という文が He could be seen by her. の様にbe動詞は、助動詞+beの形で書き換えられる。これは、be動詞の原形が beで与えられることによる。同じ様に例えば、 might be may be must be will be なども用いることが出来る。また、過去形や現在完了と組み合わせるときにも通常の規則に従えばよい。例えば、上の文では He was seen by her. He has been seen by her. などとなる。been は be の過去分詞である。ここで、be が過去分詞 been になったのは、現在完了を作るためであり、see が過去分詞 seen になったのは、受動態を作るためであることに注意。 === 不定詞 === ==== 名詞的用法 ==== ==== 形容詞的用法 ==== ==== 副詞的用法 ==== ==== 慣用的表現 ==== ==== 原型不定詞 ==== 使役動詞（make,let,have）や知覚動詞（feel,see,taste,look,hear）に係る形で不定詞の構文が作られる時、'''toは必ず抜きます。''' My mother make me <del>to</del> eat vegetables for breakfast.（私の母は、朝食の際私に野菜を食べさせる。） My father won’t let me <del>to</del> go out of parking lot at night.（私の父は、夜に駐車場へ行くことを許してくれないだろう。） 使役動詞の意味 * make - 〜させる（強制） * have - 〜してもらう（依頼） * let - 〜させる（許可） 基本的に、動詞+目的語+原型不定詞 と使う。 at はよく「6時30分に」（at 6:30 ）とか「正午」（at noon）などの時刻・時点を使うのに用いる前置詞だが、例外的に night には at を使う。 ===== 原型不定詞も取る動詞 ===== 動詞“help”は、通常の不定詞、原型不定詞のどちらも取る。 I help my brother (to) do his homework.（私は、私の兄が宿題をする事を助けた。） === 分詞 === === 動名詞 === == さまざまな構文 == === 分詞構文 === 分詞構文は現在分詞や過去分詞を用いて、従属の接続詞節のような意味を持つ文の成分を作る用法である。例文として、 Crying out something, he quickly runs away. がある。この文は「何かを叫びながら、彼は素早く逃げていった。」という 意味だが、この様な文は例えば接続詞whileを用いて、 While he cries out something, he quickly runs away 接続詞を取る。 He cries out something, he quickly runs away. 主語を取る。 Cries out some thing, he guickly runs away. 動詞を現在分詞形にする。 Crying out some thing, he quickly runs away.→'''これで完成！''' などとすることが出来る。分詞構文は文の前後関係から、省略される接続詞が予測できると考えられるとき、接続詞と主語を省略することによって 得られる。ただし、接続詞無しで節を作ることは出来ないことから、接続詞節の述語は対応する現在分詞になるのである。上の例文は while を用いた文から接続詞 while を省き、述語 cries を現在分詞 crying にすることに よって得たものと解釈出来る。ただし、元の従属接続詞節に対応する主文の主語と接続詞節の主語が等しいときには、現在分詞の主語は 省略出来る。上の文で while 節の主語に対応する語が無いのはこのことからである。 主節の主語と従属節の主語が異なっているときには、分詞構文の主語として対応する従属節の主語を所有格として与える。例えば、上の例で主語を省略せず書くと、 His crying out something, ... のようになる。 一般に現在分詞の主語を指定するときは通常所有格を用いる。 分詞構文で省略される接続詞には主なものとして、 because, since, as: 〜だから(理由) when, as, while: 〜のとき(ある時点) などがあげられる。 分詞構文になる従属節では述語がbe動詞であることがある。 このときにも上の規則に従って、Being -,によって分詞構文が作られることも多い。 ==== 分詞構文の受動態 ==== 特にbe動詞に対応する補語が受動態であったり、形容詞であるときには、beingを省いて過去分詞、もしくは形容詞から分詞構文が 始まることも多い。 (Being) seen from airport, everything looked small.（飛行機から見ると、全てのものが小さく見えた） The assignment (being) finished, we went on a hike to the nearby mountain.（その課題が終わってから、私たちは近くの山へハイキングへ行った。） このときには、be動詞と接続詞、必要なら対応する主語も補って考える必要がある。ただし、この様な省略がなされるのは、あくまで省略されたものが文脈からすぐに分かる時のみである。 === 話法 === === 会話表現 === == 品詞 == === 代名詞 === === 形容詞・副詞 === == 名詞構文・無生物主語 == === 名詞構文 === === 無生物主語 === The road takes you to the station. 「その道を歩いていくと駅につきます。」 The bus takes you to the station. 「そのバスに乗れば駅に行きます。」 take は「連れて行く」の意味だが、交通機関などを主語にして使うことも出来る。その場合は、たとえば道なら「その道を行けば、～につきます」のような意味になる。 takes の代わりに will take としても良い（ロイヤル英文法）。 「remind 人 of」 で「人に～を思い出させる」の意味である。 This picture reminds me of vacation in Greece. 「その写真を見ると、ギリシャでの休日を思い出す。」 This picture reminds me of holidays in London. 「その写真を見ると、ロンドンでの休日を思い出す。」 なお、大修館ジーニアスだとロンドン、桐原フォレストだとギリシャの例文。 「deprived 人 of ～」 「（機会などが）うばわれる」 The knee injury deprived him of the chance to play in the final game. 「ひざのけがのため、彼は決勝戦に出場する機会を失った。」 または The knee injury deprived the player of the chance to play in the game. 「ひざにけがをしたため、その選手は試合に出場する機会を失った。」 のように例文が参考書によくある。 enable ～ は、「～をできるようにする」「～を可能にする」の意味。「～のおかげで、・・・できるようになった」と訳すことができる。 The scholarship enabled him to go on to university. 「その奨学金のおかげで彼は大学へ進学できた。」 ジーニアス、ロイヤルに scholarship の似た例文。 == 疑問詞 == === 前置詞と疑問詞 === Where are you from? 出身はどちらですか？ 文法上、ここでの Where は副詞であり、「疑問副詞」というのに分類される（ロイヤル）。 さて、前置詞 from に注目しよう。 もしかしたら中学高校などで「前置詞は名詞や代名詞の前に移動するのが原則」とか習うかもしれないが、しかし前置詞をけっしてfromの前に移動しない。 なので、Where は副詞であると考えたほうが理解しやすいだろう。（これとは別の解釈で、そもそも「副詞には前置詞がいらない」という考えから副詞ではなく代名詞としての機能だと考える立場もあり、ジーニアスやロイヤルやフォレストがそういう立場。だが、机上の空論だろう。） なお、法学など幾つかの学問では、『原則』というのは例外のありうる規則、という意味である。おそらくジーニアスが「原則」という言葉を使っているのは、Where ～?などの疑問詞を文頭にもちいた疑問文の場合は例外的な事例という含みがあるのだろう。 Where に限らず、たとえば When などで疑問文を作るときも原則、それらの疑問詞の前には前置詞（When の場合は since や till や until など）を置かない。そのため、それら When の文でも前置詞は文末にくる場合が多くなる。 つまり、「いつから～？」なら When do you ～ since ? のような文章になる事が多い。 ただし、Whoの場合はやや例外的である。 たとえば前置詞 With を使う場合、Who が目的格 Whom に変化する場合もあり、 With whom do you ～? 「誰と一緒に～しますか？」 のようにWith が文頭にくる場合もある（桐原）。with以外の前置詞の場合でも文頭に持ってくる場合には同様にwhoではなく whom に変化する（ジーニアス）。なお、前置詞を文頭に持ってくる場合、whomを使わずにwho のままで文頭の前置詞の次に置くのは禁止である。 なお、Whomを使わずとも who のままで下記のように言うこともできる Who do you ～ with？ Where are you from? の場合、もし前置詞 from がないと、「あなたはどこ？」となり、それが出身をたずねているのか、それとも現在地をたずねているのか、意味が分からなくなることもあってか、ともかく 「Where are you from?」の文章は from を省略できない。 ジーニアスは、話し言葉ではWhereでは from を省略しないという言い方をしているが、しかし書き言葉であっても from を省略しないのが一般的であろう（省略したら上述のように意味が通らなり読み手に誤解を与えるので。）。 しかし、用いる動詞などによっては前置詞を省略できる場合があり、たとえば Where do you go to? 「どこに行きますか？」 なら、もし前置詞 to を省略しても、動詞 go から意味を推測できるので、この場合は to を省略されるのが許され、つまり Where do you go? でも許される（ジーニアス）。 このように文法の理論というのは、あまり論理的ではない。最終的には、英文法の学習では典型的な構文を覚えて、それを真似して使っていく必要がある。 === 慣用的な疑問文 === How about a cup of tea? 「お茶を一杯いかがですか？」 How about ～？ は勧誘を表す。 What do you say to ～ing 名詞/動名詞　？　「～はいかがですか？」「～しませんか」 What do you say to ～ing　でも勧誘を表せる。 ここでのsayの直後にある to は前置詞であると考えられている（桐原フォレスト）。どういうわけか、ジーニアスもロイヤルも、to が前置詞かどうかは言及していない。 ほか、Why don't you 動詞 ～　？ は、「～してはどうしょうか」のような相手に行為を促す（うながす）言い方であり、やや押し付けがましい言い方である（ジーニアス）。 Why don't we の形で、一緒になにかをする時に「～しましょうよ」の意味で使う場合もある（フォレスト）。 また、これを省略的に Why not ～？ の形で「～はどうですか」「～してはいかがでしょうか」「～しましょうよ」の意味にもある。 How come S + V ～？ How come ～？　は「どうして～」の意味でありwhy に近いが、How come のほうが感情的な表現であるので、目上の人に使うのは避けるのが良い（ジーニアス）。なお、How come は語順がSVと肯定形の語順になる。 How come you didn't call me ? 「どうして電話をくれなかったの？」 ※ 「電話してほしかったのに」のような含みがあり、相手を責めているようにも受け取られかねない。だから返事も、Sorry, 「ごめん」とかになる（ジーニアス）。 許可を求める表現である Do you mind if～? で、「～してもいいですか」という許可を求める表現ができる。なお Would you mind if ～? については仮定法になり、つまり「～」中の動詞が過去形になる。Would you mind if ～? については 『[[高校英語の文法/仮定法]]』で説明済み。 Do you mind if のほうは、if ～ の動詞は現在形で構わない。 == 参考文献についての注意 == サブページ中の参考文献で、現代2022年では廃止になったシリーズの桐原『フォレスト』などを掲げているが、現代でも他社の　いいずな出版『エバーグリーン』シリーズにフォレストの権利が引き継がれているようなので、わざわざ古本のフォレストを探す必要は無い。 [[カテゴリ:高等学校教育|ふむほふ]] oe5dv7ljc8frjjptg0xt010gta4qd8s 0 32845 205924 204239 2022-07-28T07:16:33Z Mtodo 450 /* 戦争への道 */ wikitext text/x-wiki {{Nav}} {{Pathnav|メインページ|小学校・中学校・高等学校の学習|小学校の学習|小学校社会|小学校社会/6学年|歴史編|frame=1}} 歴史を学ぶときに大事なことは、「その時に何が起こったか」ということ（「点」のイメージ）よりも「何が、どうして、どのように変わって、それが、どのようになったか」（「点」と「点」をつないだ「線」のイメージ）ということです。これから、歴史上の事柄を学ぶにあたって、最初に、おおまかな全体の流れを頭に入れておくと、それぞれの時代を理解する時のたすけになります。以下に、日本の歴史の大きな流れをしめします。ただし、以下のものは大きな流れをしめすため、細かくは不正確なものがありますので注意してください。 それでは、日本の歴史の流れをながめてみましょう。 == [[小学校社会/6学年/歴史編/歴史の始まり|歴史の始まり]] == <!--先史時代（縄文時代、弥生時代）から古墳時代、大和政権成立期にかけて--><!--(ア) 狩猟・採集や農耕の生活，古墳，大和朝廷(大和政権)による統一の様子を手掛かりに，むらからくにへと変化したことを理解すること。その際，神話・伝承を手掛かりに，国の形成に関する考え方などに関心をもつこと。--> ★時代区分:原始時代、石器時代、縄文時代、弥生時代、古墳時代</br> ★取り扱う年代:おおむね5世紀以前 === 狩猟・採集から農耕へ === : 大昔、日本に人々が住みはじめたころ、人々は、木の実をひろったり（採集）、動物や魚を狩などでつかまえて（狩猟）、食料や衣服としていました。このころ、ものを切ったりするのに使った道具は石でできていました。このような道具を、'''石器'''といい、この時代を「'''石器時代'''」と言います。時代がだんだん進むと、人々は、土を火で焼き固めると固くなってうつわなどが作ること（'''土器'''）ができるを発見します。最初は低い温度で厚くもろい器や人形（'''土偶'''）を作っていましたが（このような土器を「'''縄文土器'''」といい、この時代を「'''縄文時代'''」と言います）、さらに時代が進んで薄く硬い土器が作られるようになりました（このような土器を「'''弥生式土器'''」といい、この時代を「'''弥生時代'''」と言います）。 : 縄文時代から弥生時代に変わるころ、人々は狩猟・採集のくらしから田んぼや畑をたがやして米などを作る生活（'''農耕'''）をするようになりました。狩猟・採取の生活から農耕生活になると、人々は定住し「'''むら'''」ができます。人々が互いに行き来するようになると、「むら」はだんだん大きくなり、また、いくつかの「むら」が集まって「'''くに'''」となります。 === 「くに」の統一 === : 「くに」を統治する王や女王は、海を越えて中国や朝鮮半島など大陸に使者を送ったりしました。その結果、大陸から'''青銅'''や'''鉄'''を作る技術や'''文字'''（「'''漢字'''」）などの文化が流入しました。鉄器が普及したことで石器は使われることがなくなり「石器時代」は終わります。この時代、「くに」の王など有力者は、墓として「'''古墳'''」を作りましたが、そこには'''{{ruby|埴輪|はにわ}}'''などのほか、青銅製の鏡（銅鏡）などが副葬されています（この時代を「'''古墳時代'''」とも言います）。 :そして、これらの「くに」をまとめて今の日本の元を作ったのが、天皇を長とした'''{{ruby|大和|やまと}}朝廷（大和政権）'''です。統一前に「くに」をひきいていた有力者などは'''豪族'''と呼ばれます。 == [[小学校社会/6学年/歴史編/天皇中心の国づくり-飛鳥時代から奈良時代|天皇中心の国づくり-飛鳥時代から奈良時代]] == <!--飛鳥時代（聖徳太子の政策、遣隋使）から奈良時代にかけて--><!--(イ) 大陸文化の摂取，大化の改新，大仏造営の様子を手掛かりに，天皇を中心とした政治が確立されたことを理解すること。--> ★時代区分:飛鳥時代、奈良時代</br> ★取り扱う年代:おおむね6世紀以前から794年（平安遷都）まで === 飛鳥時代 === : 大和朝廷によって日本が統一されると、ますます、大陸との行き来が増えました。朝鮮半島から技術や文化を持った人々が定住し、これらを伝えました（'''渡来人'''）。また、仏教が日本に伝えられたのもこのころです。 : 当時、中国では「'''{{ruby|隋|ずい}}'''」が国を統一し強力なものとなっていました。推古天皇の皇太子である'''聖徳太子'''は、隋にならって天皇中心の強力な政治を進めるため、役人の心得をしるした「'''十七条の憲法'''」をあらわし、序列を明らかにする「'''冠位十二階'''」を定めました。また、'''小野妹子'''などを隋に派遣し（'''遣隋使'''）、隋と親交を結ぶとともに、隋の制度などを学ばせました。なお、まもなく隋は「'''{{ruby|唐|とう}}'''」に滅ぼされますが、中国への派遣はつづき、これを'''遣唐使'''と言います。また、仏教がさかんになり、'''法隆寺'''などの寺院が建てられました。これは、都が{{ruby|飛鳥|あすか}}（奈良県中部）を中心にくりひろげられたので、この時代を「'''飛鳥時代'''」と言います。 === 大化の改新 === : 聖徳太子が亡くなったのち、最も勢力を持っていた蘇我氏を中大兄皇子（後の'''天智天皇'''）は中臣鎌足（'''藤原鎌足'''、「'''藤原氏'''」の始祖）らとともに討ち、天皇中心の政治を一層強力なものにしました。例えば、土地は天皇のものとして人々に均等に分け与え、'''{{ruby|租|そ}}{{ruby|庸|よう}}{{ruby|調|ちょう}}'''といった税を徴収する制度（'''公地公民制'''）などがすすめられました。また、この時、中国にならって、初めて'''元号'''「大化」を定めました。これらの事件や改革を'''大化の改新'''と言います。このころ、朝鮮半島では'''{{ruby|新羅|しらぎ}}'''が統一を進めていて、唐と連合して'''{{ruby|百済|くだら}}'''を攻めました。百済は日本に助けを求め、日本は百済とともに新羅・唐と戦いましたがやぶれ、多くの百済の人々が日本へ移り住みました。 === 奈良時代 === : 朝廷は、国づくりをすすめるのに、'''{{ruby|律令|りつりょう}}'''という法律を作り、それにもとづく政治が行われるようになりました（'''律令制'''）。また、それまでは、天皇が変わるたびに都を移していたのですが、現在の奈良市に大規模な都「'''平城京'''（奈良の都）」を作り、そこで天皇が代わっても引き続いて政治を行うようになりました。また、このころ、初めて貨幣が作られました（'''和同開珎'''）。 : 平城京には、遣唐使で留学した僧や来日した僧によって多くの寺院が作られました。'''聖武天皇'''は即位した頃、地震や疫病などの災いが起こったのを受け、仏教に救いを求めて、全国に'''国分寺'''や'''国分尼寺'''を建立しました。これ話の総本山として奈良に'''東大寺'''をつくり、そこに大仏（'''奈良の大仏'''）を作りました。 : 平城京に都のあった時代を「'''奈良時代'''」と言います。 == [[小学校社会/6学年/歴史編/貴族の文化-平安時代|貴族の文化-平安時代]] == <!--平安京遷都から概ね平安時代--><!--(ウ) 貴族の生活や文化を手掛かりに，日本風の文化が生まれたことを理解すること。--> ★時代区分:平安時代</br> ★取り扱う年代:794年（平安遷都）から1192年（鎌倉幕府の成立）まで === 貴族の政治 === : 794年、桓武天皇は、現在の京都市に都「'''平安京'''」を造営し遷都します。これから、約400年を「'''平安時代'''」と言います。 : このころになると、公地公民がくずれ出し、自分で開墾した農地は子孫に伝えてもよくなり、さらに、その農地を寺院や朝廷の有力者に寄付をし自らはそれを管理する領主となって税をのがれることができるようになりました。寺院や朝廷の有力者は、こうして、大きな土地を支配するようになり、朝廷と独立した経済力を持つようななりました。この土地を'''{{ruby|荘園|しょうえん}}'''と言います。このような荘園を持つ、朝廷の有力者を'''貴族'''（{{ruby|公家|くげ}}）と言っています。貴族を代表するのは、藤原鎌足を祖先にもつ'''藤原氏'''です。藤原氏は、娘を天皇の{{ruby|妃|きさき}}にすることで、天皇家との関係を深め、'''摂政'''・'''関白'''といった天皇の仕事を代行する役職についたほか、重要な役職を一族で独占し朝廷を主導しました（'''摂関政治'''）。 === 平安時代の文化と生活 === : 大陸からの文化をうけいれた日本は、遣唐使の派遣が減り、ついには廃止されたこともあり、だんだん日本の風土や慣習に合わせた独自の文化をかたちづくっていきました。漢字を元にした「'''かな'''（ひらがな、かたかな）」を使用することで、日本語を自由に記述できるようになり、'''和歌'''を中心とした日本文学がさかんになります。やがて、和歌の由来から物語が発達し、日記や随筆など、さまざまな分野の文学が花開きました。このような文学は、特に、藤原氏出身の妃の周囲の女官（'''女房'''）が多くの作品を残しました。藤原氏が最も栄えた'''藤原道長'''の時代には、『'''源氏物語'''』を書いた'''紫式部'''や『'''枕草子'''』を書いた'''清少納言'''がいました。 : 奈良時代の仏教は、災いをしずめ国を守ることを目的としたり、深く経を研究するなど学問的なものでしたが、平安時代の初期に'''空海'''と'''最澄'''が現れ、それぞれ、「'''真言宗'''」と「'''天台宗'''」を開きました。真言宗は日本中に布教され、庶民までに普及しました。一方、天台宗の総本山'''比叡山延暦寺'''は、僧の修行の場として現代の大学のような役割を果たし、多くの仏教指導者を生み出します。平安時代の中期頃から、'''末法思想'''が流行し、極楽往生を願う'''浄土信仰'''が盛んとなります。道長の子藤原頼道が作った'''宇治平等院鳳凰堂'''は浄土信仰による寺院の代表です。 === 武士の誕生 === : 全国の農地の多くが荘園となり、税収が減ったため朝廷による治安の取り締まりは十分ではなくなりました。荘園領主らは、自ら武装したり、武装した者をやとうなどして、自衛しました。これが、'''武士'''の始まりです。平安時代の中期頃から朝廷と対立し各地で反乱が起きたりします。この反乱をしずめるのも、やはり武士でした。 == [[小学校社会/6学年/歴史編/武家社会の始まり-鎌倉時代|武家社会の始まり-鎌倉時代]] == <!--保元平治の乱あたりから元寇まで、鎌倉時代--><!--(エ) 源平の戦い，鎌倉幕府の始まり，元との戦いを手掛かりに，武士社会による政治が始まったことを理解すること。--> ★時代区分:鎌倉時代</br> ★取り扱う年代:1192年（鎌倉幕府の成立）から1333年（鎌倉幕府の滅亡）まで === 源平の戦い === : 平安時代末期には、武士がいなければ治安は保たれなくなっていました。武士は、日本各地で強力なリーダーの下で集団となって武士団となりました。武士団の中でも強力なものが'''平氏'''（平家）と'''源氏'''です。平氏は主に瀬戸内海の海賊の取り締まりで、源氏は関東地方や東北地方の反乱鎮圧で勢力を伸ばしました。1156年天皇家や藤原氏のあとつぎについて、双方が武士団を味方につけて争いました。この争いで、武士が中央の政治にかかわるようになり、1160年に'''平清盛'''が政権をとって、それ以降、天皇や貴族から政治の実権は武士が握るようになりました。 : 平氏は一族のみで政権を独占し、他の武士団の利益を顧みなかったことなどから、他の武士団の反発をまねき各地で反乱が起きました。清盛が死去すると、源義仲（木曾義仲）が平氏を都から追い出し、鎌倉に勢力を有する'''源頼朝'''が弟'''源義経'''などに命じて、義仲と平氏を滅ぼしました（'''源平の戦い'''）。頼朝は1192年'''征夷大将軍'''（将軍）というすべての武士の長に任ぜられ、鎌倉に将軍の役所である'''幕府'''を開きます。これを、「'''鎌倉幕府'''」といい、鎌倉に幕府がある時代を「'''鎌倉時代'''」と言います。 === 鎌倉幕府 === : 頼朝は、自分の家来である武士（'''{{ruby|御家人|ごけにん}}'''）を各国の軍事や治安を取りまとめる'''守護'''や各荘園を管理する'''地頭'''に任じて全国を支配しました。頼朝の死後、頼家・実朝の三代で源氏の将軍家は終わりますが、それ以降は将軍を補佐する'''{{ruby|執権|しっけん}}'''の職にあった'''北条氏'''が武士を取りまとめ政治を行いました。各地の治安が安定すると、産品を遠距離輸送する商業などが見られるようになり、人々の生活が多様で豊かなものになってきました。こうした生活の変化は、仏教にも及び、浄土教（'''浄土宗'''・'''浄土真宗'''・'''時宗'''）、'''禅宗'''（'''臨済宗'''・'''曹洞宗'''）、'''法華宗'''（日蓮宗）などがおこり、武士や庶民といった民衆に受け入れられました。 === 元寇 === : そのころ、モンゴルがはげしい勢いでユーラシア大陸全土にわたって勢力範囲を広げており、中国には「'''元'''」という国を打ち立てていました。元は朝鮮半島も領土とし、さらに日本に攻め入りました（'''{{ruby|元寇|げんこう}}'''）。執権'''北条時宗'''は、全国の御家人や武士を集め、これを撃退しました。しかし、幕府は得るものがなかったので恩賞を十分に与えることができず、各地の武士に不満が残りました。 == [[小学校社会/6学年/歴史編/室町文化の誕生-室町時代|室町文化の誕生-室町時代]] == <!--室町時代−主題は文化史--><!--(オ) 京都の室町に幕府が置かれた頃の代表的な建造物や絵画を手掛かりに，今日の生活文化につながる室町文化が生まれたことを理解する こと。--> ★時代区分:建武の新政、南北朝時代、室町時代（前期）</br> ★取り扱う年代:1333年（鎌倉幕府の滅亡）から1467年（応仁の乱の開始）まで === 室町幕府の誕生 === : 元寇の後、恩賞の不足などから武士が貧しくなるなどして、世の中が乱れました。'''後醍醐天皇'''は、執権北条氏を倒して政治の改革をしようと全国の武士に呼びかけ、北条氏を滅ぼし、新たな政治を始めます（'''建武の新政'''）。しかし、この新政は、公家が優先されるなどから、多くの武士の不満を生じさせ、この不満を受けた'''足利尊氏'''は、後醍醐天皇に反して別の天皇を立て、征夷大将軍に任ぜられ京都に幕府を開きます。これを、「'''室町幕府'''」といい、この時代を「'''室町時代'''」と言います。また、このころ、後醍醐天皇とその子孫が天皇の朝廷（南朝）と尊氏が立てた天皇の朝廷（北朝）がともにあった時期があり、これを「'''南北朝時代'''」と言います。 : 鎌倉幕府の滅亡から南北朝の争いを通じて、守護・地頭と言った御家人や各土地の武士は、朝廷領や荘園の管理の立場から直接に支配するようになってきました。このようにして大きな領地を得ることになった守護を'''守護大名'''と言います。また、各地で領主となった武士を'''{{ruby|国人|こくじん}}'''と言います。 === 室町時代の文化 === : 南北朝の争いは、第三代将軍'''足利義満'''のときに、南朝が降伏しおさまります。義満は、その他有力な守護大名を押さえるなどして、戦乱の世をおさめ安定した世の中を実現します。また、中国の「'''{{ruby|明|みん}}'''」に使いを送り、貿易を開始します（'''勘合貿易'''）。この貿易から、日本に大量の貨幣（'''永楽通宝'''）が流入し、商業が盛んとなるきっかけになりました<!--貨幣経済が発展した-->。 : 義満は、京都北山に別荘「'''金閣'''」を建てました、また、第八代将軍'''足利義政'''は東山に「'''銀閣'''」を建てました。これらのつくりには、ふすまや畳、違い棚と言った現在の和風建築に生かされているものを見ることができます。義満は、'''観阿弥'''・'''世阿弥'''といった'''能楽'''の始祖を保護し、能楽とそれからわかれ出た'''狂言'''は日本の演劇のみなもととなります。この時代は、京都だけではなく、守護大名の治める地方都市でも文化が花開くようになります。'''水墨画'''の'''雪舟'''はこの時期の代表的な芸術家ですが、守護大名大内氏のもと、現在の山口市などで活躍しました。 == [[小学校社会/6学年/歴史編/戦乱の世の中と日本の統一-戦国時代・安土桃山時代|戦乱の世の中と日本の統一-戦国時代・安土桃山時代]] == <!--戦国時代から織豊時代--><!--(カ) キリスト教の伝来，織田・豊臣の天下統一を手掛かりに，戦国の世が統一されたことを理解すること。--> ★時代区分:戦国時代（室町時代後期）、安土桃山時代</br> ★取り扱う年代:1467年（応仁の乱の開始）から1600年（関ヶ原の戦い）まで === 戦国時代 === : 義政のころになると、守護大名は幕府にたよらず領地を強力におさめるようになり、そのため、各地では大名同士や国人同士での勢力争いも数多く見られるようになりました。特に、義政の後継者争いをきっかけにした'''応仁の乱'''以後は、幕府は各地の争いを止める力を失って大名間で競って領土を争うようになります。この時代を「'''戦国時代'''」と言います。 : 戦国時代にあっては、世襲の守護大名に対して、実力のある家臣などが大名の地位を乗っ取ることがしばしば見られました（'''下克上'''）。このように実力で大名となり、周囲の大名と争った大名を'''戦国大名'''と言います。また、長槍・投石など単純な兵器を軽装で扱う兵士（'''足軽'''）を大量に用いて集団でたたかうようになりました。特に、'''鉄砲伝来'''が、この戦い方に影響を与えました。 : 15世紀から、西ヨーロッパの国々、特に'''ポルトガル'''と'''スペイン'''は世界中に船を出して貿易を始めたり、新たな土地を発見したりしていました（'''大航海時代'''）。その中で、1543年種子島にポルトガル人が漂着し、鉄砲が伝えられました。日本への航路を発見したポルトガルとスペインは、日本では'''南蛮人'''と呼ばれ、各地の戦国大名などと貿易を行います（'''南蛮貿易'''）。また、'''フランシスコ・ザビエル'''が来日し、'''キリスト教'''を伝えました。 === 安土桃山時代 === : 実力のある戦国大名が、周囲の戦国大名などを討ち取って、各地での統一が進んでいましたが、戦乱の世の中を治め日本全体を統一に向かわせたのは'''織田信長'''です。信長は、領地の商業を盛んにし財力を拡大し<!--検地の実施（生産力の把握）、楽市楽座、貨幣経済への指向（永楽銭の旗印）-->、身分に関わりのない人材の登用、鉄砲など新たな武器の使用などで、領国の現在の愛知県から京都周辺の近畿地方一帯を統一し、将軍を追放し室町幕府を滅ぼしました。しかし、家臣の明智光秀により殺され、光秀を討った'''豊臣秀吉'''が信長の天下統一を引き継ぎます。信長は滋賀県の安土に城をきずき政治を行い、それをついだ秀吉は京都の桃山城（現在の京都市伏見区）で政治を行なったので、この時代を「'''安土桃山時代'''」と言います。政治の中心は桃山（伏見）でしたが、秀吉は、豊臣家の城として'''大坂城'''（大阪城）をきずき、城下に大名屋敷や堺などの周辺の町々の町人を集めて、'''大坂'''（大阪）の町を築いて政治・経済の中心都市としました。 : 秀吉は、中国地方の毛利氏、四国地方の長宗我部氏、九州地方の島津氏などを攻めしたがえ、関東を支配する北条氏を攻めほろぼして、天下を統一します。天下を統一した秀吉は、全国の農地の測量を行い（'''検地'''）、どれくらい米が収穫できるかを明らかにし（'''太閤検地'''）、大名の財力の基準としました（'''{{ruby|石高|こくだか}}制'''）。この機会に、長さ・広さ・体積の単位が統一されました。また、天下が統一され、平和になったのだから武器は必要ないであろうということで、刀などを取り上げる「'''{{ruby|刀狩|かたながり}}'''」を行いました。刀狩で、武士とそうでない民衆は明確に区別されました。 : 秀吉が、天下を統一したころには、キリスト教の信者（'''キリシタン'''）はかなり増えており、大名の中にも信者がいました（キリシタン大名）。しかし、各地で寺社との対立があったり、スペインなどの侵略のうわさなどもあり、宣教師（バテレン）を国外に追放し、キリスト教の布教を禁止しました。 : 晩年、秀吉は、大陸進出を望んで、全国の大名に命じて朝鮮に兵を進めました（'''朝鮮出兵''': 文禄・慶長の役）。しかし、朝鮮の強い抵抗と、明の援軍にあい、侵攻が進まないなか、秀吉が死去し朝鮮出兵は撤退しました。 == [[小学校社会/6学年/歴史編/江戸幕府の成立と安定した社会-江戸時代Ⅰ|江戸幕府の成立と安定した社会-江戸時代Ⅰ]] == <!--徳川幕府の成立、江戸時代初期（概ね島原の乱あたりまで）--><!--(キ) 江戸幕府の始まり，参勤交代や鎖国などの幕府の政策，身分制を手掛かりに，武士による政治が安定したことを理解すること。--> ★時代区分:江戸時代初期</br> ★取り扱う年代:1600年（関ヶ原の戦い）から1638年（島原の乱終結）まで === 江戸幕府の始まり === :秀吉死後、最も強力な大名'''徳川家康'''は、敵対する豊臣家家臣石田三成らと、東軍（家康側）と西軍（三成側）に分かれ関ヶ原で戦い（'''関ヶ原の戦い'''）、これに勝利します。政権は豊臣氏から徳川氏に移ります。 :関ヶ原の戦いに勝利した'''徳川家康'''は、1603年に征夷大将軍に就任し、'''江戸'''に幕府を開きます。これを「'''江戸幕府'''（または、徳川幕府）」といい、江戸に幕府があった時代を「'''江戸時代'''」と言います。家康は、大坂冬の陣・夏の陣で豊臣氏を滅ぼし、これ以降、大名同士の合戦はなくなります。 :関ヶ原の戦いの後、家康は西軍の大名の領地と豊臣氏の領土を取り上げ、東軍の大名に分け与えました。この時、大名を家康の子孫による'''親藩'''、関ヶ原の戦い前から家来である'''{{ruby|譜代|ふだい}}大名'''、関ヶ原の戦い後に従った'''{{ruby|外様|とざま}}大名'''にわけてとりあつかいました。①親藩は、将軍家の血筋が絶えた場合などに、将軍を出す役割を担った'''御三家'''・'''御三卿'''を含み、家格・官位などでは優遇されましたが、幕政に参加することはまれでした、②譜代大名は、比較的小さな石高の領土を認められ領地替えもよくありましたが、江戸や京大阪からは近くに位置したものでした。'''大老'''、'''老中'''、'''若年寄'''といった幕閣には譜代大名がつきました。③外様大名は、比較的大きな石高の領土を認められ、幕末まで領地替えはほとんどありませんでしたが、江戸や京大阪からは遠いところにありました。また、幕政に参加することはほとんどありませんでした。なお、江戸時代の大名とその家来を合わせた集団を、「'''{{ruby|藩|はん}}'''」と言っています。幕府は強力な力を持っていましたが、藩の中の政治に口を出すことはありませんでした。 === 武士の政治の安定 === :第3代将軍'''徳川家光'''は、大名は、妻子（正妻と後継となる子）を江戸に置き、領土との間を1年おきに行き来すること（'''参勤交代'''）を定めました。また、将軍の命令で、徳川氏が有する城や河川の改修などを務めなければならないこともありました。こうして、徳川将軍は大名が、戦国時代のように勝手に争うことができないようにし、安定した世の中を作り上げました。 :徳川幕府には、重要なことを決める大老、老中、若年寄の他、大名の監視を行う'''大目付'''、寺社を管理する'''寺社奉行'''、幕府の出納を管理する'''勘定奉行'''、江戸の行政や裁判を行う'''江戸町奉行'''などの役職があり、大名の他、将軍の直接の家臣である'''旗本'''がその任務につきました。 :秀吉の刀狩によって、武士の身分（士分）と民衆が明確に分けられましたが、江戸幕府はそれを引き継ぎ、「'''士農工商'''」という身分制を確立しました。<!--なお、以前は、身分がこの順にあったと言われていましたが、現在では「士分」とその他は身分差があるが、「農工商」には身分の差がなかったというのが定説となっています。-->また、人の移動は厳しく制限され、各地に関所がもうけられ、ここを通るのに通行手形が必要でした。 :キリスト教は秀吉の時代に禁じられましたが、江戸幕府においても禁じられました。一方で、ポルトガルなどとの貿易は港を限定しながらも続いており、そこで宣教師との行き来があったとされます。そんな中、九州の天草・島原で大規模なキリスト教徒による反乱（'''島原の乱'''）が起きました。これがきっかけとなって、幕府は、島原の乱の翌年に、貿易の相手を、キリスト教の布教には熱心でない'''オランダ'''だけに限って、さらに、長崎の'''出島'''だけでこれを認めることになりました。これを、'''{{ruby|鎖国|さこく}}'''と言います。 == [[小学校社会/6学年/歴史編/江戸時代の文化-江戸時代Ⅱ|江戸時代の文化-江戸時代Ⅱ]] == <!--江戸時代中期−主題は文化史（元禄文化、化政文化など）--><!--(ク) 歌舞伎や浮世絵，国学や蘭学を手掛かりに，町人の文化が栄え新しい学問がおこったことを理解すること。--> ★時代区分:江戸時代中期</br> ★取り扱う年代:1638年（島原の乱終結）から1853年（ペリー来航）前まで === 江戸時代の文化 === :江戸幕府の様々な政策によって世の中は安定し、人々は安心して経済活動を行えるようになって、様々な文化が武士だけでなく町人にも栄えるようになりました。 :「'''{{ruby|元禄|げんろく}}'''」は、江戸幕府ができてだいたい100年くらいの元号ですが、このころ、最初の町人文化の開花が見られました。元禄の頃の文化を「'''元禄文化'''」と言います。仮名草子・浮世草子といった出版物が市中に出回るようになり、'''人形浄瑠璃'''や'''歌舞伎'''が人々に人気を得て、'''井原西鶴'''や'''近松門左衛門'''といった小説家・劇作家がでました。 :連歌から発達した'''俳句'''（俳諧）が流行し、'''松尾芭蕉'''は、それを芸術のレベルまで高めたと言われています。 :絵画も大衆化し、このころ'''菱川師宣'''が'''浮世絵'''を創始しました。浮世絵は、版画の一種で何枚も同じ絵をすることができるので、庶民でもこれを買い求めることができました。ただし、浮世絵については、元禄から、さらに100年ほど後の「文化」「文政」といった元号の時期に最も盛んになります('''化政文化''')。'''喜多川歌麿'''や'''東洲斎写楽'''は歌舞伎役者の肖像画を、'''歌川広重'''は『東海道五十三次絵』などの風景画を、'''葛飾北斎'''は『冨嶽三十六景』など風景画のほか様々な構図の絵をあらわし、国内のみならず、オランダ貿易で持ち出されたものがフランスなどの絵画にも影響を与えました。 === 江戸時代の学問 === :戦国時代までの学問は主に寺院で、僧侶などにより、仏教や中国の古典が研究されていましたが、江戸時代になると、様々な階層の人々の研究が見られるようになります。 :幕府が公認していた学問は'''儒学'''のうち'''朱子学'''と言われるもので、幕府のほか各藩で教えられました。その他、中国の古典が研究されました。 :一方で、日本の古典についても研究が進み、'''国学'''が成立しました。国学の成立に大きく貢献したのが'''本居宣長'''です。国学は、のちの「'''尊王攘夷'''」の考えに影響します。 :鎖国をしているので、ヨーロッパの文化には直接触れることはできなかったのですが、オランダ語の書物を出島をとおして、手に入れることができ、これを訳して読むことで、当時急速に進みつつあったヨーロッパの科学に触れることができました。このような学問を'''蘭学'''と言います。'''杉田玄白'''らはオランダ語の医学書を翻訳して『'''解体新書'''』をあらわしました。 :'''伊能忠敬'''は、天文学や測量術を学んだ他、独自に測量方法を工夫し、日本全国を訪れ、正確な日本地図を作りました。 == [[小学校社会/6学年/歴史編/明治維新と近代国家日本の成立-幕末・明治時代|明治維新と近代国家日本の成立-幕末・明治時代]] == <!--黒船来航から倒幕、明治政府成立までー幕末から明治時代初期　(ケ) 黒船の来航，廃藩置県や四民平等などの改革，文明開化などを手掛かりに，我が国が明治維新を機に欧米の文化を取り入れつつ近代化を進めたことを理解すること。--> ★時代区分:幕末、明治維新、明治時代前期</br> ★取り扱う年代:1853年（ペリー来航）から1889年（大日本帝国憲法の発布）まで === 黒船来航と江戸幕府の終わり === : 日本が鎖国をしている間、ヨーロッパやそれを受けたアメリカ大陸では大きな社会変革が起こっていました。「'''産業革命'''」です。産業革命によって、石炭を使って大量の製鉄ができ、蒸気機関によって大きな力を得て、蒸気機関車や蒸気船といった、大量かつ高速輸送が可能となりました。欧米各国は、産業革命で巨大になった経済力を背景に世界中に船を出すなどして、製品の{{ruby|市場|しじょう}}を求めるようになりました。 : 1853年'''アメリカ合衆国'''（米国）の提督'''ペリー'''が4隻の蒸気船（'''黒船'''）を引き連れ、浦賀に来航し日本に開国を要求しました。幕府は大混乱の中、翌年の再来日をうけ、米国の船舶が港湾を利用することなどを認める'''日米和親条約'''を結び、その後、米国以外のヨーロッパ各国とも同様の条約を結び、1639年以来の鎖国は解かれました。欧米各国はさらに日本との貿易の条件などに関する通商条約の締結を求めます。日本国内では天皇が治める国であって（尊皇）外国人を入れるべきではない（攘夷）という考え（'''尊王攘夷'''）が全国的に起こり、幕府の動きがこれに反するものとして対立し、大老'''井伊直弼'''はこれを弾圧しました。井伊直弼は'''通商条約'''締結を強行しますが、尊王攘夷派に暗殺されます。日本は長い間他の国と外交をすることがなかったので、国際法の知識に乏しく、この時に結ばれた通商条約は、「'''治外法権'''」があって、「'''関税自主権'''」を認められない日本にとって不平等な条約でした。'''長州藩'''と'''薩摩藩'''は尊皇攘夷の代表でしたが、欧米諸国に日本は大きく遅れており、それに追いつくには、「攘夷」ではなく積極的に外国に学ぶことであり、幕府の仕組みではうまくいかないと考えて、同盟して（薩長同盟）、幕府をうちたおすこと（倒幕）に方針を変えました。1867年第15代将軍'''徳川慶喜'''は、征夷大将軍を辞任し（'''{{ruby|大政奉還|たいせいほうかん}}'''）、江戸城は、薩摩の西郷隆盛らの率いる新政府に明け渡されました。こうして、江戸幕府は終わり、武士の世の中が終わります。 === 明治維新と文明開化 === : 幕府が倒れた後、薩摩藩の'''西郷隆盛'''、'''大久保利通'''、長州藩の'''木戸孝允'''らの働きによって'''明治天皇'''を中心とした新政府がつくられました（'''王政復古'''）。明治天皇の名による'''五箇条の御誓文'''が発布され新政府の方針がしめされ、様々な改革に取り組みます。元号が「'''明治'''」に改められたことをうけて、この改革を「'''{{ruby|明治維新|めいじいしん}}'''」といいます。新政府は幕府だけでなく、藩も廃止し、政府が全国を直接治める形に変えました（'''廃藩置県'''）。また、'''四民平等'''をうたって、武士の特権を否定しました。新政府は、法律・裁判・軍隊・警察・経済・金融・税制・機械工業・鉄道・郵便・電信・学校・暦など数多い分野で、欧米を模範にした改革を行いました。 : これらの改革によって、たとえば、布地が安く手に入るようになったり、蒸気機関車で短時間で遠くまで移動できるようになるなど人々の生活は大きく便利に変わりました（'''文明開化'''）。また、身分制をなくしたので、生まれた家に関わらず、個人の努力によって政治をはじめとする社会のあらゆる分野にかかわることができるようになりました。このような社会にあった「自由」や「平等」など「権利」「人権」といった欧米の考え方が'''福沢諭吉'''などにより紹介されました。 == [[小学校社会/6学年/歴史編/国際社会に進み出す日本-明治末期から大正時代|国際社会に進み出す日本-明治末期から大正時代]] == <!--1889年前後から「国際的地位が向上」（1920年国際連盟成立 常任理事国入り）まで--><!--(コ) 大日本帝国憲法の発布，日清・日露の戦争，条約改正，科学の発展などを手掛かりに，我が国の国力が充実し国際的地位が向上したことを理解すること。--> ★時代区分:明治時代後期、大正時代</br> ★取り扱う年代:1889年（大日本帝国憲法の発布）から1925年（昭和改元）まで === 大日本帝国憲法の制定 === : 明治維新の改革は、五箇条の御誓文の方針によりなされましたが、改革が進み近代文明国としての形がひととおり整ってきたところ、さらに政治の形を確かなものとし、人々の権利を明らかにするため、'''憲法'''の制定と選挙によって選ばれた議員による議会を開くことが求められました。'''板垣退助'''や'''大隈重信'''は国会の開設を求めて、政党をつくりました。'''伊藤博文'''を中心とした明治政府は欧米諸国の憲法を研究し、1885年に'''内閣制度'''が創設され、1889年に'''大日本帝国憲法'''が発布されました。翌年憲法の精神に基づいて<!--憲法施行は議会召集以降-->、初めて総選挙が行われ'''帝国議会'''（国会）が召集されました。 === 日清戦争と日露戦争 === : 急激な近代化に成功した日本は、国内で拡大した産業の新たな市場を求め大陸に進出しようとします。朝鮮は中国の帝国'''{{ruby|清|しん}}'''の属国でしたが、その影響で近代化が進んでおらず、朝鮮国内の近代化を求める人々は日本と協力して清の影響から逃れようとしました。朝鮮国内の清に従う保守派と改革派の争いに日本と清はそれぞれ兵を出すなどして緊張が高まり、1894年朝鮮半島西岸における両国海軍の接触をきっかけに'''日清戦争'''が始まりました。日本は清の北洋海軍を壊滅させ、遼東半島を占領するなど戦いを有利に進め、翌年、'''陸奥宗光'''外務大臣と清の提督である李鴻章が交渉し、清の日本への賠償や台湾・遼東半島の割譲などを定めた下関条約が締結され講和が結ばれました（日本の勝利）。 : 遼東半島はロシア、ドイツ、フランスが反対したので割譲は取りやめとなりましたが（三国干渉）、そこにロシアが進出し、それを警戒する日本と対立しました。1904年日本とロシアは開戦し（'''日露戦争'''）、日本とロシアは、ロシアが植民地としていた遼東半島や中国東北部（満州）で戦いました。日本は多くの犠牲者を出しましたが、'''東郷平八郎'''がロシアのバルチク艦隊をやぶるなどして有利な位置となり、翌年、'''小村寿太郎'''外務大臣とロシアのウィッテが交渉し、ロシアの中国からの撤退、南満州鉄道の譲渡、南樺太の割譲などを定めたポーツマス条約が締結され講和が結ばれました（日本の勝利）。 === 条約改正と国際社会での地位の向上 === : 幕末に欧米各国と結ばれた通商条約（不平等条約）の改正は日本政府の悲願でした。まず、政府は、国内の法整備を進め、公正な裁判が行われることを示し、日清戦争終結後の1899年治外法権を撤廃しました。そして、日露戦争の勝利は、世界に驚きをもってむかえられ、国際的地位も上がったことをうけて、1911年関税自主権も回復しました。 : 1912年大正天皇が即位し、元号が「'''大正'''」となりました。 : 1914年にヨーロッパの国々を二分した'''第一次世界大戦'''が始まりました。日本は、イギリスやフランスの属する連合国に参加し、敵対する同盟国の一つであるドイツが租借する中国の{{ruby|青島|チンタオ}}や南太平洋の島々を占領しました。1919年戦争は連合国の勝利に終わり、翌年、平和を維持するための'''国際連盟'''が設立、日本は英仏などとともに常任理事国の一つとなりました。 : このころになると、日本の科学技術の水準も世界的なものになり、'''野口英世'''のように国際的な研究者がでてくるようになりました。 == [[小学校社会/6学年/歴史編/戦争への道と現代の民主国家日本の誕生-昭和から現在まで|戦争への道と現代の民主国家日本の誕生-昭和から現在まで]] == <!--(サ)日中戦争や我が国に関わる第二次世界大戦，日本国憲法の制定，オリンピック・パラリンピックの開催などを手掛かりに，戦後我が国は民主的な国家として出発し，国民生活が向上し，国際社会の中で重要な役割を果たしてきたことを理解すること。--> ★時代区分:昭和時代、平成時代、令和</br> ★取り扱う年代:1926年（昭和改元）以降 === 戦争への道 === : 1926年昭和天皇が即位し、元号が「'''昭和'''」となりました。 : 日本経済は、第一次世界大戦終結後、長く低迷を続けていましたが、1929年に'''世界恐慌'''が起きるとさらに景気が悪くなりました。人々の一部は、中国東北部（満州）の開発で、これを解決しようとしました。こうして、'''中華民国'''との間に対立が生まれ、1931年から戦争状態となります。全世界を見ても、世界恐慌から回復しようと自国を優先した政策をとるようになります。こうして、世界は第一次世界大戦前のような状態になってきました。特に1919年ロシア革命で生まれた'''ソビエト連邦'''（ソ連）に対しては、日本はドイツ・イタリアと同盟するなど各国から警戒されました。こうした中、1939年ドイツはポーランドに侵攻し'''第二次世界大戦'''が始まりました。1940年、ドイツはフランスに侵攻、1941年にはソ連に侵攻するなど戦争が拡大しました。日本は、中国との戦争を非難するアメリカ合衆国との交渉がうまくいかず、1941年ドイツ側に参戦し、アメリカやイギリスと戦うことになりました。この戦争は、戦車や飛行機といった最新の強力な兵器が使われ、大量の犠牲者が出ました。日本も、中国をはじめとしたアジア各地で住民に損害を与えた一方で、戦争の後期には、日本各地で'''空襲'''を受け、沖縄は全土が戦場となり、そして、広島・長崎に'''原子爆弾'''が落とされるなど、歴史上見なかった被害を出して、戦争に敗れました。 === 民主国家日本の誕生と発展 === : 日本は、戦勝国であるアメリカ合衆国の占領下に入り、その下で、「国民主権」「基本的人権の尊重」「平和主義」を三大原則とした'''日本国憲法'''が制定されるなどさまざまな民主化政策が行われます。そうして世の中が安定すると、日本は品質の高い工業製品を世界中に輸出することで、経済力を回復し（'''高度経済成長'''）、国民生活が向上すると同時に、国際社会の一員として復帰しました。その象徴が、1964年に開催された'''東京オリンピック'''と'''パラリンピック'''です。その後も、万国博覧会、2回の冬季オリンピックやサッカーワールドカップなど世界的な催し物を開催できるようになりました。2021年世界中が'''コロナ禍'''で沈む中、2回目の'''東京オリンピック・パラリンピック'''を開催したことは記憶に新しいところです<!--指導要領に「1964年に開催された東京オリンピックとパラリンピック」が強調されており、無視するわけにもいかず付言する。指導要領作成時にはこの事態は当然想定しておらず、成功する前提で話題としているに違いない-->。 ---- {{前後 |type=章 |[[小学校社会/6学年/歴史編]] |[[小学校社会/6学年/歴史編/歴史の流れをつかもう|日本の歴史の流れ]] |[[小学校社会/6学年/歴史編/はじめに|はじめに]] |[[小学校社会/6学年/歴史編/歴史の始まり|歴史の始まり]] }} [[Category:社会|しようかつこうしやかい6]] [[Category:小学校社会|6ねん]] [[Category:小学校社会 歴史|#02]] 7ecv2rdckabvdetx3vjg025zqhriklb 0 34689 205919 205609 2022-07-27T22:39:52Z Ef3 694 /* for と Range と if */ ジェネレータに、if で修飾することができます（Guardといいます）。[[Python]]の[[Python#内包表記とジェネレータ式|ジェネレータ式]]に似た表現です。 wikitext text/x-wiki {{Pathnav|メインページ|工学|情報技術|プログラミング|frame=1}} {{Wikipedia}} 本書は、[[w:Scala|Scala]]のチュートリアルです。 Scalaは、[[W:汎用プログラミング言語|汎用プログラミング言語]]の１つで、[[W:関数型プログラミング|関数型プログラミング言語]]と[[W:オブジェクト指向プログラミング|オブジェクト指向プログラミング言語]]のハイブリッドです。 <!-- イントロ長すぎ！ 「はじめに」か「コラム」する構成を検討中 --> Scalaのソースコードは、[[W:Javaバイトコード|Javaバイトコード]]にコンパイルされ、[[W:Java仮想マシン|Java仮想マシン]]（JVM）上で実行することができます。 Scalaは、[[Java]] との相互運用性を提供しており、どちらの言語で書かれたライブラリもScalaやJavaのコードで直接参照できます。 Scalaは、Javaと同じくオブジェクト指向で、[[C言語]]に近いカーリーブラケット構文<ref>カーリーブラケットとは波括弧 <code>{}</code> のことで、コードブロックやデータブロックの表現に使われます。</ref>を持ちます。 Scala 3以降、ブロックの構造にオフサイドルール（インデント）を使用するオプションもあり、その使用が推奨されています。 Scalaは、Javaとは異なり関数型プログラミング言語（[[Lisp]]・[[Scheme]]・[[OCaml]]・[[Standard ML]]・[[Haskell]] など）の多くの特徴を持っており、カリー化・イミュータブル性・遅延評価・パターンマッチが含まれます。 また、代数的データ型・共分散と共変量・高次演算子（ただしパラメトリック多相性は除く）や匿名型もサポートする先進の型システムも備えています。 その他、JavaにないScalaの特徴として、演算子オーバーロード・オプションのパラメータ・名前付きパラメータ・Raw文字列があります。 逆に、ScalaにないJavaの特徴として、チェック付き例外があり、これについての議論は続いています。 Scalaという名前は、''scalable''と''language''の合成語で、ユーザーの要求に合わせて成長するように設計されていることを意味しています。 <!-- ベクトル・スカラー のスカラーは scalar です。英語では vector/ヴェクター・scalar/スケーラー に近い発音です。 --> __TOC__ == はじめに == === Hello, World! === 他の多くのチュートリアルがそうであるように、私たちもまずはScalaの世界にあいさつすることから始めましょう。 ''hello.scala''というファイルを作り(Scalaではソースファイルに''.scala''という拡張子を付けることが通例となっています)、次のように書いて保存して下さい。 ;[https://paiza.io/projects/QNLS9UYljt6PgoAzPZPWbA?language=scala hello.scala]:<syntaxhighlight lang=Scala> object Main extends App{ println("Hello world!") } </syntaxhighlight> == 環境 == * オンライン開発実行環境 * Javaとscalaのインストールとバージョン確認 == コメント == Scalaのコメントの構文は2つあります *// から行末までがコメントになります // 一行コメント * /* から */ までがコメントなります（他の多くのプログラミング言語と違いネスト（入れ子）に出来ます） /* 複数行にまたがることが出来るコメント /* ネスト１ /* ネスト２ */ */ */ == ; の自動挿入 == Scalaでは、JavaScriptやGoの様に ; が自動挿入されます。 ❌ var x = 1 + 2 + 3 ⭕ var x = 1 + 2 + 3 == 変数と型とリテラル == Scalaは、関数型プログラミング言語ですが、純粋関数言語ではないので変数があります。 === 変数の宣言と初期化と参照 === Scalaで変数を使うためには、宣言が必要です。 ==== val：イミュータブル変数宣言 ==== ;[https://paiza.io/projects/cQSDnyoWVrZZ1niEXur3xw?language=scala コード例]:<syntaxhighlight lang=Scala> // val i: Int = 0 // !!! error: expected class or object definition !!! object Main extends App { val i: Int = 123 // i = 0 // !!! error: reassignment to val !!! println(i) } </syntaxhighlight> ;実行結果:<syntaxhighlight lang=text> 123 </syntaxhighlight> : 1行目は、Object の定義の外で宣言しようとしても失敗する例です。 :: Scala には、グローバル変数はありません。 :: // から行末まではコメントになります。 : object Main の中で、Int型の変数 i を宣言し、123 で初期化しています。 : val で宣言した i に 0 を代入しようとしていますがエラーになります。 :: val で宣言した変数に、代入する事は出来ません。この様な変数を'''イミュータブル'''な変数と言います。 : <code>println(i)</code> の様に、変数の値は変数名（この場合は <var>i</var>）を使って参照できます。 ==== var：ミュータブル変数宣言 ==== ;[https://paiza.io/projects/m7W0SR6MfF9i4obsqJz4rg?language=scala コード例]:<syntaxhighlight lang=Scala> // var i: Int = 0 // !!! error: expected class or object definition !!! object Main extends App { var i: Int = 123 i = 0 println(i) } </syntaxhighlight> ;実行結果:<syntaxhighlight lang=text> 0 </syntaxhighlight> : 1行目は、Object の定義の外で宣言しようとしても失敗する例です。 :: ミュータブルであっても、グローバル変数は作れません。 : object Main の中で、Int型の変数 i を宣言し、123 で初期化しています。 : var で宣言した i には 0 を代入する事ができます。この様な変数を'''ミュータブル'''な変数と言います。 ==== 変数宣言に関する詳細 ==== ===== 未初期化はコンパイルエラー ===== ;[https://paiza.io/projects/j8TR9XpQJgHf-649jReSDA?language=scala コード例（コンパイルエラー）]:<syntaxhighlight lang=Scala highlight=2 line> object Main extends App { var i: Int println(i) } </syntaxhighlight> ;コンパイル結果:<syntaxhighlight lang=text> 1 error Main.scala:2: error: only traits and abstract classes can have declared but undefined members (Note that variables need to be initialized to be defined) var i: Int ^ </syntaxhighlight> ===== _ を使ったディフォルト値を使った初期化 ===== ;[https://paiza.io/projects/db05Fc4iWgF226hG5uAd6Q?language=scala コード例]:<syntaxhighlight lang=Scala highlight="2,4,6,8" line> object Main extends App { var i: Int = _ println(i) var f: Boolean = _ println(f) var s: String = _ println(s) var m: Map[String, Int] = _ println(m) } </syntaxhighlight> ;実行結果:<syntaxhighlight lang=text> 0 false null null </syntaxhighlight> : 識別子 <code>_</code> を初期化に使うと、その型のディフォルト値で初期化されます。 :: 数値は 0、Boolean は false、他は null がディフォルト値となります。 :: [[Go]] のゼロ値と似ていますが、明示的に _ で初期化するところが違います。 ===== 同じ式による複数の変数の初期化 ===== ;[https://paiza.io/projects/8kUN8FqfxdoL9YDlB37_dg?language=scala コード例]:<syntaxhighlight lang=Scala highlight="2,5,8-9" line> object Main extends App { val i, j, k = 42 println(i, j, k) val u, v, w = new Array(5) println(u, v, w) var n: Int = 0 val x, y, z = { n += 1 ; n } println(x, y, z) } </syntaxhighlight> ;実行結果:<syntaxhighlight lang=text> (42,42,42) ([Ljava.lang.Object;@7c16905e,[Ljava.lang.Object;@2a2d45ba,[Ljava.lang.Object;@2a5ca609) (1,2,3) </syntaxhighlight> : 複数の変数を、一度に宣言し同じ'''式'''<ref>値ではなく式です。</ref>で初期化することが出来ます。 : <code>val i, j, k = 42</code> で <var>k<var> だけではなく <var>j<var> も <var>i<var> も初期化されます。 : 初期化の式は、リテラルである必要はなく、初期化される宣言毎に評価されます。 :: <code>val u, v, w = new Array(5)</code> の <code>new Array(5)</code> は、３回評価され、その都度新しいインスタンスが生成されます。 :: <code>val x, y, z = { n += 1 ; n }</code> の <code>{ n += 1 ; n }</code> は、３回評価され、その都度インクリメントされるので、[[C言語]]の列挙型 enum と同じ機能が実現できます。どちらかと言うと [[Go]]の <code>iota</code> ですね。 ::: <code>{ n += 1 }</code> ではなく <code>{ n += 1 ; n }</code> なのは、 <code>n += 1</code> の値は <var>n</var> ではなく <code>()</code> だからです。 ::: このため、Scala では <code>x = y = 42</code> とは出来ず（x に () が入ってしまう）、<code>(x, y) = (42, 42)</code> のようにします。 ===== パターンマッチ ===== 変数宣言にもパターンマッチングが使えます。 val (x, y) = ( 178, 901 ) val v @ (a, a) = ( 42, 78 ) val m @ Array(n0, n1, _*) = Array(2,3,5,7,11) ===== lazy val：遅延評価 ===== ;[https://paiza.io/projects/tO047BQjIHxY37OsapSNdg?language=scala コード例]:<syntaxhighlight lang=Scala highlight="4-6,8" line> object Main extends App { var a = 3 var b = 4 lazy val c = { println("!"); a * b } a = 0 println(c) a = 100 println(c) } </syntaxhighlight> ;実行結果:<syntaxhighlight lang=text> ! 0 0 </syntaxhighlight> : <code>lazy val</code> で宣言された変数は、はじめて参照された6行目で評価 :: この時に参照されるのは、5行目で更新された <var>a</var> の値が参照されるので、クロージャではありません。 :: 8行目で再び、<var>c</var> を参照すると、7行目での <var>a</var> の変更は反映されません。一度、評価されたら値は変わりません。 '''lazy var''' は出来ません。 ---- {{コラム|val? var? どちらを使うべき？|2= 変数を宣言するとき「valで宣言するか var で宣言すべきか？」、 言い換えると、「変数をイミュータブルにすべきか？」と言う質問になります。 関数プログラミングの観点からは、そもそも変数（＝副作用）は邪道なのですが、 あえて変数を使うのであれば、まず val（イミュータブル）で宣言し、代入が行われるようなら var（ミュータブル）に変更するという基本戦略が考えられます。 幸いScalaは、イミュータブルな変数とミュータブルな変数に使える名前（変数名）の規則は同じで、参照するときも追加の記号は必要ありません。 }} === 型推論 === 先の例では、変数を型を指定して宣言していました。 Scalaには、型推論機構があるので、初期値が与えられる変数宣言では初期値から変数の型が推論され型名を明示する必要はなくなります。 ;型推論:<syntaxhighlight lang=Scala> object Main extends App { val i = 123 var j = 12 println(i) println(j) } </syntaxhighlight> ;実行結果:<syntaxhighlight lang=text> 123 12 </syntaxhighlight> === 数値のリテラル表現 === Javaの数値はオブジェクトではなくプリミティブ型ですが、Scalaでは数値もオブジェクトです。 また型名にも違いがあるので、対照表にしてみました。 :{| class="wikitable" |+ JavaとScaleの型の対照表 ! Javaでの型 || Scalaでの型 || サイズ || リテラル表現 |- | char || Char || 2バイト || 'A', '漢' |- | byte || Byte || 1バイト || -128:Byte |- | short || Short || 2バイト || 123:Short |- | int || Int || 4バイト || 1234567890, -2147483648 |- | long || Long || 8バイト || 123L, -9223372036854775808L |- | float || Float || 4バイト || 3.1415926536f |- | double || Double || 8バイト || 3.1415926536 |- | boolean || Boolean || 1バイト || true, false |} == ブロック == Scalaでは、カーリーブラケット構文を使ってブロックを表します。 ブロックの最後の式の値が、ブロックの値になります。 ;ブロックとブロックの値:<syntaxhighlight lang=Scala line> object Main extends { val x = { val (a, b) = (1, 2) println("Hello!") a + b } println(x) } </syntaxhighlight> ;実行結果:<syntaxhighlight lang=text> Hello! 3 </syntaxhighlight> : <code>val (a, b) = (1, 2)</code>は、タプルを使った変数の宣言です。 : これらの変数のスコープはブロック末の '}' までで、それ以降は参照できません（ブロックスコープ）。 == 関数 == Scalaでは、「0個以上のパラメータを受取ることの出来る式」を関数と呼びます。 他の言語では、アロー関数やラムダ式と呼ばれる概念です。 ;関数:<syntaxhighlight lang=Scala line> object Main extends App { val add = (x: Int, y: Int) => x + y val msg = () => "hello!" println(add(1, 2)) println(add(1999, 1)) println(msg()) println(((a: Int,b: Int)=>a*b)(9, 11)) } </syntaxhighlight> ;実行結果:<syntaxhighlight lang=text> 3 2000 hello! 99 </syntaxhighlight> : 関数には名前がないので、変数に一旦に束縛し変数（変数名）を使って呼出します。 : 8行目では、変数を介さず定義したその場で実行しています（無名関数の即時実行）。 === 無名関数のアンダースコアを使った簡略表記 === ;[https://paiza.io/projects/h5Hh9tmcCbXIuXc-PpZx-A?language=scala コード例]:<syntaxhighlight lang=Scala highlight="3,5"line> object Main extends App { println((0 to 4).map(x => x * 3)) println((0 to 4).map(_ * 3)) println((0 to 4).reduce((x, y) => x + y)) println((0 to 4).reduce(_ + _)) println((0 to 4).map(x => x * x)) // 参照が二回以上ある場合は明示的に名前をつける } </syntaxhighlight> ;実行結果:<syntaxhighlight lang=text> Vector(0, 3, 6, 9, 12) Vector(0, 3, 6, 9, 12) 10 10 Vector(0, 1, 4, 9, 16) </syntaxhighlight> ===== パイプラインスタイル ===== パイプラインスタイルは、JavaScriptなどでよく使うメソッドチェインですが、イテレータメソッドが演算子の様に見える書き方です。 [[#For と Range と if|for と Range と if]]の例をパイプラインスタイルで置換えてみます。 ;例:<syntaxhighlight lang=Scala highlight=0 line> object Main extends App { // for (i <- 0 to 10 if i % 2 != 0) println(i) (0 to 10) filter { _ % 2 != 0 } foreach { println(_) } } </syntaxhighlight> ;実行結果:<syntaxhighlight lang=text> 1 3 5 7 9 </syntaxhighlight> 関数合成ではないので、<code>(0 to 10) filter { _ % 2 != 0 }</code> が先に評価され、そのオブジェクトに <code> .foreach({ println(_) })</code> が提供されるので、場合によっては要素数の多いコレクション・オブジェクトが中間結果として生成されるので注意してください。<!--関数合成を紹介しよう!--> == メソッド == メソッドは、コードを再利用する仕組みで、関数と似ていますが、両者は別個のものです。 メソッドはclass、object、trait内でキーワードdefを使って定義します。 ;メソッド:<syntaxhighlight lang=Scala line> object Main extends App { def add(x: Int, y: Int): Int = x + y def msg: String = "hello!" println(add(1, 2)) println(add(1999, 1)) println(msg) } </syntaxhighlight> ;実行結果:<syntaxhighlight lang=text> 3 2000 hello! </syntaxhighlight> : これだけ観ると、構文はともかく関数とメソッドの差は大きく感じられません。 : 強いていうと、空の引数リストは定義も呼出しも () を付けないところが違います。 これまで、頻繁に使ってきた <code>println()</code> も、Predefオブジェクトのメソッドで、Predefオブジェクトは暗黙に import されるので特別な準備なく使えました。 === 遅延評価パラメータ === Scalaでは、メソッドや関数の引数は値渡しですが、遅延評価にすることが出来ます。 これによって、制御構造を関数定義する道が開きます。 ;[https://paiza.io/projects/TUhXbh6yml2ScepcpNMGoA?language=scala メソッド]:<syntaxhighlight lang=Scala line> object Main extends App { def f1(x: Boolean, t: Unit, f: Unit) = if (x) t else f f1(true, println("True"), println("False")) def f2(x: Boolean, t: => Unit, f: => Unit) = if (x) t else f f2(true, println("真"), println("偽")) } </syntaxhighlight> ;実行結果:<syntaxhighlight lang=text> True False 真 </syntaxhighlight> == メインメソッド == メインメソッドは、プログラムのエントリーポイントです。 == 制御構造 == Scalaも、多くのプログラミング言語と同じく、「逐次」「分岐」「反復」の 3 種類の制御構造を持ちます。 Scalaの制御構造は、全て値を持ちます。この事は、Scalaの If'''式''' は、[[C言語]]の三項演算子と等価であることを示します。 === Scala 3 の新構文 === Scala 3 では、括弧<code>()</code> を使わない新しい構文が追加されました。 新構文の登場で、'''旧構文が使えなくなることはない'''ので、Scala 2の為に書かれたプログラムが使えなくなるような事はありません<ref>2から3へのアップデートと言うと、python2とpython3の非互換性の悲劇を思い起こす方も多いと思いますが、Scaleでは原則的に下位互換性があります。</ref>。 {| |+ 旧・新構文の対応 |- !Scala 2!!Scala3 |- |style="width:45%"|<syntaxhighlight lang=Scala line> object Main extends App { val x = 0 val xs = 0 to 4 val ys = 0 to 5 if (x < 0) "負" else if (x == 0) "零" else (x > 0) "正" else "何" if (x < 0) -x else x while (x >= 0) print(x, " ") for (x <- xs if x > 0) yield x * x for ( x <- xs; y <- ys ) println(x + y) } </syntaxhighlight> |style="width:45%"|<syntaxhighlight lang=Scala line> object Main extends App { val x = 0 val xs = 0 to 4 val ys = 0 to 5 if x < 0 then "負" else if x == 0 then "零" else x > 0 then "正" else "何" if x < 0 then -x else x while x >= 0 do print(x, " ") for x <- xs if x > 0 yield x * x for x <- xs; y <- ys do println(x + y) } </syntaxhighlight> |} === 分岐 === ==== if ==== if式は、条件式に基づいて分岐し分岐先の式を評価します。 if式の値は、分岐先の式の値です。 ;構文:<syntaxhighlight lang=ebnf> if-expr := if '(' 条件式 ')' 式1 [ else 式2 ] </syntaxhighlight> : 条件式は、Boolean 型でなければいけません。 : <code>else 式2</code>の部分はオプショナルで、省略され条件式が false であった場合、if式はUnit 型の値 <code>()</code> 単位ユニットが式の値となります（要素個数ゼロのタプルです）。 : elseif elsif のたぐいはないので、<code>else if (条件式2) 式3</code> と続けます。 ;[https://paiza.io/projects/y8p_q50uEL2IE71JfNrxNw?language=scala if式の例]:<syntaxhighlight lang=Scala line> object Main extends App { val i = 0 if (i == 0) println("zero") else println("non zero") println({ if (i == 0) "Zero" else "Non zero" }) println({ if (i != 0) "NON ZERO" }) } </syntaxhighlight> ;実行結果:<syntaxhighlight lang=text> zero Zero () </syntaxhighlight> ==== match ==== C言語のswicth文は、式と一致するリテラルのラベルへの多方向GOTO文ですが、Scalaのmatch式はパターンマッチングに基づいています。 ;構文:<syntaxhighlight lang=ebnf> match-expr := 式 match ’{’ ( パターン => 式 )+ ’}’ </syntaxhighlight> : 式の値に、合致するパターンはないか上から順に走査し、合致したパターン対応する式が評価され、この値がmatch式の値となります。 : 式に対して、パターンがどれも合致しないとコンパイル時のフロー解析の結果わかった場合、コンパイルエラーになります。 : このため、全てにマッチするパターン _ が最後に置かれることが常となります。 :: ただし式が、Boolean や enum の場合は、網羅チェックを台無しにするので _ を使うべきではありません。 ;[https://paiza.io/projects/kMzZMXaBj2rARbop3Lcn0A?language=scala match式の例]:<syntaxhighlight lang=Scala line> object Main extends App { val n = 10 n match { case 1 => println("壱") case 2 => println("弐") case 3 => println("参") case _ => println("多数") } println({ n match { case 1 => "一" case 2 => "二" case 3 => "三" case _ => "膨大" } }) println({ n match { case 1 => "一" case 2 => "二" case 3 => "三" // case _ => "膨大" // ここをコメントにしてしまうと、網羅性がほころびコンパイルエラーになる } }) } </syntaxhighlight> ;実行結果:<syntaxhighlight lang=text> 多数 膨大 膨大 </syntaxhighlight> === 反復 === ==== while ==== while式は、条件式が true の間、式を評価しつづけます。 while式の値は、評価した式の値です。 ;構文:<syntaxhighlight lang=ebnf> while-expr := while '(' 条件式 ')' 式 </syntaxhighlight> : 条件式は、Boolean 型でなければいけません。 ;[https://paiza.io/projects/A8RXe7wm4tuqv_N-EaeiuQ?language=scala while式の例]:<syntaxhighlight lang=Scala highlight="4-7" line> object Main extends App { var i = 0 while (i < 5) { println(i) i += 1 } println(s"last = $i") } </syntaxhighlight> ;実行結果:<syntaxhighlight lang=text> 1 2 3 4 last = 5 </syntaxhighlight> : Scalaには、<code>変数 ++</code> の様なインクリメント演算子はなく、<code>変数 += 1</code> の構文を使います。 :: これは、Scala の整数はイミュータブルなためで、同じ理由で [[Ruby]] にもインクリメント演算子はありません。 :: また、<code>変数 += 1</code> は、<code>変数 = 変数 + 1</code>の構文糖です。 :: さらに、<code>変数 + 1</code> は、<code>変数 .+(1)</code>の構文糖です。 ::: 加算に限らず、Scalaの演算子は、メソッドの構文糖です。 : <var>i</var> のスコープは、object Main なのでループを抜けても値を参照出来ます。 : <code>s"last = $i"</code> は、加工文字列リテラル(''processed string literal'') で、文字列の中で変数の値を参照できます。 ==== do - while ==== Scala 3 で、do - while　は'''廃止'''になりました。 while の条件式に繰返し部分と続行条件を書き、ループ本体は空にすることで do - while を模倣できます。 ;[https://paiza.io/projects/iluJn2pkYxfJwzHWflWPpw?language=scala do - while の模倣]:<syntaxhighlight lang=Scala highlight="4-8" line> object Main extends App { var i = 10 while ({ println(i) i += 1 i < 5 }) {} println(s"last = $i") } </syntaxhighlight> ;実行結果:<syntaxhighlight lang=text> 10 last = 11 </syntaxhighlight> ==== for ==== Scalaのfor式は、ジェネレータに対してイテレーションを行います。 ;構文:<syntaxhighlight lang=ebnf> for-expr := for '(' ジェネレータ ')' 式 </syntaxhighlight> ===== for と Range ===== ;[https://paiza.io/projects/eWKe2_2XTuJQPh2NzkZNTA?language=scala for式とRangeクラスの例]:<syntaxhighlight lang=Scala highlight=0 line> object Main extends App { println(0 to 4) for (i <- 0 to 4) println("to: " + i) println(0 until 4) for (i <- 0 until 4) println("until: " + i) } </syntaxhighlight> ;実行結果:<syntaxhighlight lang=text> Range 0 to 4 to: 0 to: 1 to: 2 to: 3 to: 4 Range 0 until 4 until: 0 until: 1 until: 2 until: 3 class scala.collection.immutable.Range$Inclusive </syntaxhighlight> : <code>0 to 4</code> や <code>0 until 4</code> は、Rangeクラスのオブジェクトで範囲を表します。 : <code>0 to 4</code> や <code>0 until 4</code> は、Rangeクラスのリテラル、、ではなく <code>to</code> と <code>until</code> は演算子で : <code>0.to(4)</code> や <code>0.until(4)</code> と言うメソッドの演算子表記<!--Need to verify if terminology is appropriate-->です。 ===== for と Range と if ===== ジェネレータに、if で修飾することができます（Guardといいます）。[[Python]]の[[Python#内包表記とジェネレータ式|ジェネレータ式]]に似た表現です。 ;[https://paiza.io/projects/tpIREeZXCqIKIaE81eFfcA?language=scala for式とRangeクラスとif式の例]:<syntaxhighlight lang=Scala highlight=0 line> object Main extends App { for (i <- 0 to 10 if i % 2 != 0) println(i) } </syntaxhighlight> ;実行結果:<syntaxhighlight lang=text> 1 3 5 7 9 </syntaxhighlight> ===== 二重ループ ===== ２つのジェネレーターを <code>;</code> で区切ると多重ループを構成出来ます。 ;[https://paiza.io/projects/MUXX893zSMN8DDftVS6lBQ?language=scala 二重ループ]:<syntaxhighlight lang=Scala highlight=0 line> object Main extends App { for ( i <- 0 to 2; j <- 0 to 3 ) { println((i, j)) } } </syntaxhighlight> ;実行結果:<syntaxhighlight lang=text> (0,0) (0,1) (0,2) (0,3) (1,0) (1,1) (1,2) (1,3) (2,0) (2,1) (2,2) (2,3) </syntaxhighlight> ===== 値を返す for ===== for式と <code>yeild</code> の組合せでfor式は値を返すことが出来ます。 ;[https://paiza.io/projects/qqgyaWk2Of2jfOsj35RGug?language=scala 値を返す for]:<syntaxhighlight lang=Scala highlight=0 line> object Main extends App { println(for (i <- 0 to 4) yield i.toString) } </syntaxhighlight> ;実行結果:<syntaxhighlight lang=text> Vector(0, 1, 2, 3, 4) </syntaxhighlight> === 脱出 === ==== return ==== ブロックからの脱出には、return を使います。 break や continue はありません。 == 例外処理 == ScalaにはJavaのthrows節がありません<ref>[[Java]]の場合は、例外を発生させる可能性のあるメソッドは、throws節で発生させる例外の種類をすべて宣言する必要があります。 ただし、RuntimeException（RuntimeExceptionの派生クラス）の場合は、throws節で明示的に記述する必要はありません。</ref>。 すべての例外はメソッドの外側に投げることができます。 ;例外処理:<syntaxhighlight lang=Scala highlight=4 line> object Main extends App { try { val n = 1 n / 0 println("return!") } catch { case e: Exception => { println("Exception caught.") println(e.getMessage) println(e.getStackTrace) } } finally { println("done!") } } </syntaxhighlight> ;実行結果:<syntaxhighlight lang=text> Exception caught. / by zero [Ljava.lang.StackTraceElement;@35a74ae9 done! </syntaxhighlight> : finally 節の式は、例外の有無に関係なく実行されます。 :: try 節や catch 節 で exit() すると、流石に finally 節は実行されません。 == クラス == Scalaは、関数型プログラミング言語であると同時に、オブジェクト指向プログラミング言語です。 より厳密に言うと、（プロトタイプベースではなく）クラスベースのオブジェクト指向プログラミング言語です。 クラス(''class'')は、オブジェクトを作る雛形で、クラスから new 演算子を使ってオブジェクトを作ることをインスタンス化、出来たオブジェクトの事をインスタンスと呼びます。 === クラス定義とインスタンス化とメソッド === ;[https://paiza.io/projects/41inK-Tl-w-FIjRvurIs3Q?language=scala コード例]:<syntaxhighlight lang=Scala highlight="2-5" line> object Main extends App { class Hello(val s: String = "world") { override def toString: String = s"Hello $s!" def print: Unit = println(s) } val hello1 = new Hello() println(hello1) hello1.print val hello2 = new Hello("my friend") println(hello2) print(s""" Hello.getClass() === ${Hello.getClass()} hello1 === ${hello1} hello2.s = ${hello2.s} """) } </syntaxhighlight> ;実行結果:<syntaxhighlight lang=text> Hello world! world Hello my friend! Hello.getClass() === class Main$Hello$ hello1 === Hello world! hello2.s = my friend </syntaxhighlight> : [[Ruby#クラス]]の例を、Scala に移植しました。 : 冒頭4行がクラス定義です。 : クラス定義に、他のオブジェクト指向言語ならコンストラクタに渡すような引数が渡されています。 : メンバーを公開するケースなら、この様に宣言的な引数リストを使うとメンバー定義と暗黙の初期値を与えられます。 : toString は、オブジェクトを文字列化するメソッドで、Objectの同名のメソッドをオーバーライドしています。 : print は、このクラスに独自なメソッドで、println() の値 == () == Unit を戻値型としています。 === 少しまとまったサイズのクラス === [[Ruby#ユーザー定義クラス]]の都市間の大圏距離を求めるメソッドを追加した例を、Scalaに移植。 ;[https://paiza.io/projects/U0m9xY_SSy4X-MLnplj-0A?language=scala ユーザー定義クラス]:<syntaxhighlight lang=Scala line> object Main extends App { class GeoCoord(val longitude: Double = 0.0, val latitude: Double = 0.0) { override def toString: String = { var (ew, ns) = ("東経", "北緯") var (long, lat) = (longitude, latitude) if (long < 0.0) { ew = "西経" long = -long } if (lat < 0.0) { ns = "南緯" lat = -lat } s"(${ew}: ${long}, ${ns}: ${lat})" } def distance(other: GeoCoord): Double = { val i = Math.PI / 180 val r = 6371.008 Math.acos( Math.sin(this.latitude * i) * Math.sin(other.latitude * i) + Math.cos(this.latitude * i) * Math.cos(other.latitude * i) * Math.cos(this.longitude * i - other.longitude * i) ) * r } } val Sites = Map( "東京駅" -> new GeoCoord(139.7673068, 35.6809591), "シドニー・オペラハウス" -> new GeoCoord(151.215278, -33.856778), "グリニッジ天文台" -> new GeoCoord(-0.0014, 51.4778) ) Sites.foreach { case (k, v) => println(s"${k}: ${v}") } val keys = Sites.map { case (k, v) => k }.toList val len = keys.size for (i <- 0 until len) { val (ksi, ksx) = (keys(i), keys((i + 1) % len)) println(s"${ksi} - ${ksx}: ${Sites(ksi).distance(Sites(ksx))} [km]") } } </syntaxhighlight> ;実行結果:<syntaxhighlight lang=text> 東京駅: (東経: 139.7673068, 北緯: 35.6809591) シドニー・オペラハウス: (東経: 151.215278, 南緯: 33.856778) グリニッジ天文台: (西経: 0.0014, 北緯: 51.4778) 東京駅 - シドニー・オペラハウス: 7823.269299386704 [km] シドニー・オペラハウス - グリニッジ天文台: 16987.2708377249 [km] グリニッジ天文台 - 東京駅: 9560.546566490015 [km] </syntaxhighlight> == ケースクラス == ;[https://paiza.io/projects/R2pOOT-Yp-xk-BURc_P9Xw?language=scala コード例]:<syntaxhighlight lang=Scala highlight="2,29-31" line> object Main extends App { case class GeoCoord(longitude: Double = 0.0, latitude: Double = 0.0) { override def toString: String = { var (ew, ns) = ("東経", "北緯") var (long, lat) = (longitude, latitude) if (long < 0.0) { ew = "西経" long = -long } if (lat < 0.0) { ns = "南緯" lat = -lat } s"(${ew}: ${long}, ${ns}: ${lat})" } def distance(other: GeoCoord): Double = { val i = Math.PI / 180 val r = 6371.008 Math.acos( Math.sin(this.latitude * i) * Math.sin(other.latitude * i) + Math.cos(this.latitude * i) * Math.cos(other.latitude * i) * Math.cos(this.longitude * i - other.longitude * i) ) * r } } val Sites = Map( "東京駅" -> GeoCoord(139.7673068, 35.6809591), "シドニー・オペラハウス" -> GeoCoord(151.215278, -33.856778), "グリニッジ天文台" -> GeoCoord(-0.0014, 51.4778) ) Sites.foreach { case (k, v) => println(s"${k}: ${v}") } val keys = Sites.map { case (k, v) => k }.toList val len = keys.size for (i <- 0 until len) { val (ksi, ksx) = (keys(i), keys((i + 1) % len)) println(s"${ksi} - ${ksx}: ${Sites(ksi).distance(Sites(ksx))} [km]") } } </syntaxhighlight> ;実行結果:<syntaxhighlight lang=text> 東京駅: (東経: 139.7673068, 北緯: 35.6809591) シドニー・オペラハウス: (東経: 151.215278, 南緯: 33.856778) グリニッジ天文台: (西経: 0.0014, 北緯: 51.4778) 東京駅 - シドニー・オペラハウス: 7823.269299386704 [km] シドニー・オペラハウス - グリニッジ天文台: 16987.2708377249 [km] グリニッジ天文台 - 東京駅: 9560.546566490015 [km] </syntaxhighlight> : コンストラクタ引数に val がなくても、自動的にフィールドが宣言されます。 :: var なフィールドを希望する場合は、var を明示します。 : インスタンス化する時、new は必要ありません。 :: コンパニオンオブジェクトが自動的に生えてきます。 == シングルトン・オブジェクト == object は、たった1つのインスタンスを持つクラス（＝シングルトン）です。 これは、lazy valのように、参照されたときに（遅延して）生成されます。 object は、トップレベルの値としてはシングルトンであり、 クラスのメンバやローカルな値としては、lazy val と全く同じ振る舞いをします。 === シングルトン・オブジェクトの定義 === シングルトン・オブジェクトは値です。シングルトン・オブジェクトの定義はクラスのように見えますが、object というキーワードを使用します。 シンプルなシングルトン object Simple == トレイト == トレイト('''trait''')は、[[Java]]の[[Java/インターフェース|インターフェース]]と[[Java/抽象クラス|抽象クラス]]の中間的な存在です。 実装を持ったインターフェースで、コンストラクタのパラメータを持つことができませんが、[[オブジェクト指向プログラミング#Mix-in|ミックスイン]]( ''mix-in'' )することが出来ます。 * 抽象クラスと同様に、トレイトは具象メンバを持つことができますが、インスタンス化することはできません。 * インターフェイスと同様に、クラスは複数のトレイトのメンバを継承することができます。 * クラスはトレイトで拡張することができます。<syntaxhighlight lang=Scala> class C extends Trait1 { ... } </syntaxhighlight> * クラスや他の特徴を継承することができます。<syntaxhighlight lang=Scala> trait T1 extends Class1 { ... } trait T2 extends Trait1 { ... } </syntaxhighlight> * クラス、オブジェクト、トレイトはトレイトの中で混在することができます。<syntaxhighlight lang=Scala> class C extends Trait1 with Trait2 with Trait3 { ... } val obj = new Class1() with Trait1 with Trait2 with Trait3 { ... } </syntaxhighlight> == 脚註 == <references /> == 参考文献 == * {{Cite web |url=https://www.scala-lang.org/files/archive/spec/2.13/ |title=Scala Language Specification <nowiki>|</nowiki> Scala 2.13 |publisher= École Polytechnique Fédérale, Lausanne (EPFL) Lausanne, Switzerland |date=2022/06/10 |accessdate=2022/06/24 }} * {{Cite web |url=https://docs.scala-lang.org/scala3/reference/ |title=Scala 3 Reference |publisher= École Polytechnique Fédérale, Lausanne (EPFL) Lausanne, Switzerland |date=2022/06/01 |accessdate=2022/06/24 }} == 外部リンク == * [https://www.scala-lang.org/ The Scala Programming Language] ** [https://docs.scala-lang.org/ja/ ドキュメント｜Scala Documentation] {{スタブ}} [[Category:Scala|*]] [[Category:プログラミング言語]] {{NDC|007.64}} 1odvn0rljmr6789r7vvt2zaupl0d3ui 0 35257 205926 2022-07-28T08:10:24Z すじにくシチュー 12058 勧誘 must wikitext text/x-wiki == must == === 勧誘 must === must には、強い勧誘を意味する用法もある（インスパイア、桐原ファクトブック、ジーニアス）。 You must ～. 「ぜひ～してください」「ぜひ～したほうがいい」 のような意味。 青チャートには書いていない。（あまり重要視してないのだろう。） 欧米人は、この手の、外国人には分かりづらい、やや飛躍気味の表現をすることもよくある。 :※ 飛躍気味とは、たとえば最近の俗語の例では、英米人の近年の若者などの用法で、すばらしい絵や文芸を見たときに、「その絵を消してくれ」なんていう表現も最近の英語では良く使われるという。どうやら「素晴らしすぎて、魅了されて、頭がおかしくなってしまいそうだ」→「だから消してくれ」という意味らしいのだが、しかし事情が知らない外国人が聞くと、単にその絵や文芸に不満があるかと誤解されかねない。しかし、英語は世界の覇権言語なので、外国人からの誤解を気にする必要も無い。日本人からすれば、まったく、英米人はうらやましい限りである。 この 勧誘の must を紹介しているインスパイア、ジーニアスも、コラム的に紹介しているだけである。（桐原ファクトのみ、本文で紹介。） :※ 昔から教育評論でよく言われる、英語教育の隠れた目的のひとつとして、誤解の恐れの少ない論理的な文章の書き方の教育を教える、という目的がある。文科省や国立大学などは、中立性などの理由で、「論理的な日本語の書き方はこうあるべきし」とは宣言できないので、仕方なく英文法など外国語を使って論理的な文章の書き方を教えようとしている、などとは昔はよく評論されたものである（もっとも、最近の英語教育では会話重視などで、そういう論理性の教育目的は雲散霧消してしまったが）。そういう論理的な文章の書き方の教育としては、勧誘 must やら上記例の「消してくれ」のような飛躍気味の用法は、嫌われるだろうから、大学入試などに勧誘の must などが出る可能性は低いかもしれない。 == 確信「ちがいない」 must の否定 == 「～にちがいない」という強い確認の意味での must の否定は、 cannot 「～はずがない」である（ジーニアス、インスパイア、青チャート）。 なぜそうかといわれても、そうだと決まってる。英米人がそういう使い方をしているので、合わせるしかない。 :※ これまた、あまり論理的でないので、おそらく入試では問われづらいだろう。たとえば桐原ファクトでは、確信の否定 cannot を無視しており、非紹介である。 h68onjs58blbg6d1e1pnmx2px8v91hf 205927 205926 2022-07-28T08:22:20Z すじにくシチュー 12058 wikitext text/x-wiki == must == === 勧誘 must === must には、強い勧誘を意味する用法もある（インスパイア、桐原ファクトブック、ジーニアス）。 You must ～. 「ぜひ～してください」「ぜひ～したほうがいい」 のような意味。 青チャートには書いていない。（あまり重要視してないのだろう。） 欧米人は、この手の、外国人には分かりづらい、やや飛躍気味の表現をすることもよくある。 :※ 飛躍気味とは、たとえば最近の俗語の例では、英米人の近年の若者などの用法で、すばらしい絵や文芸を見たときに、「その絵を消してくれ」なんていう表現も最近の英語では良く使われるという。どうやら「素晴らしすぎて、魅了されて、頭がおかしくなってしまいそうだ」→「だから消してくれ」という意味らしいのだが、しかし事情が知らない外国人が聞くと、単にその絵や文芸に不満があるかと誤解されかねない。しかし、英語は世界の覇権言語なので、外国人からの誤解を気にする必要も無い。日本人からすれば、まったく、英米人はうらやましい限りである。 この 勧誘の must を紹介しているインスパイア、ジーニアスも、コラム的に紹介しているだけである。（桐原ファクトのみ、本文で紹介。） :※ 昔から教育評論でよく言われる、英語教育の隠れた目的のひとつとして、誤解の恐れの少ない論理的な文章の書き方の教育を教える、という目的がある。文科省や国立大学などは、中立性などの理由で、「論理的な日本語の書き方はこうあるべきし」とは宣言できないので、仕方なく英文法など外国語を使って論理的な文章の書き方を教えようとしている、などとは昔はよく評論されたものである（もっとも、最近の英語教育では会話重視などで、そういう論理性の教育目的は雲散霧消してしまったが）。そういう論理的な文章の書き方の教育としては、勧誘 must やら上記例の「消してくれ」のような飛躍気味の用法は、嫌われるだろうから、大学入試などに勧誘の must などが出る可能性は低いかもしれない。 == 確信「ちがいない」 must の否定 == 「～にちがいない」という強い確認の意味での must の否定は、 cannot 「～はずがない」である（ジーニアス、インスパイア、青チャート）。 なぜそうかといわれても、そうだと決まってる。英米人がそういう使い方をしているので、合わせるしかない。 :※ これまた、あまり論理的でないので、おそらく入試では問われづらいだろう。たとえば桐原ファクトでは、must の項目では、確信の否定 cannot を無視しており、非紹介である。なお、桐原でも can の側で cannot「～はずがない」を説明しており、可能性 can の否定として cannot「～はずがない」 という用法を説明するというのが桐原ファクトの理論構成である。 cannot や can't と言った場合、単に「～できない」という可能性を否定するだけの用法もあるが（インスパイア　can側）、それとは別に「～のはずがない」という強めの否定である「否定の確信」な意味の場合もある（桐原ファクト、ジーニアス）。 hsnan0gg3s1y0z2o15yahcaqu36e8nq 205928 205927 2022-07-28T08:24:09Z すじにくシチュー 12058 /* 確信「ちがいない」 must の否定 */ wikitext text/x-wiki == must == === 勧誘 must === must には、強い勧誘を意味する用法もある（インスパイア、桐原ファクトブック、ジーニアス）。 You must ～. 「ぜひ～してください」「ぜひ～したほうがいい」 のような意味。 青チャートには書いていない。（あまり重要視してないのだろう。） 欧米人は、この手の、外国人には分かりづらい、やや飛躍気味の表現をすることもよくある。 :※ 飛躍気味とは、たとえば最近の俗語の例では、英米人の近年の若者などの用法で、すばらしい絵や文芸を見たときに、「その絵を消してくれ」なんていう表現も最近の英語では良く使われるという。どうやら「素晴らしすぎて、魅了されて、頭がおかしくなってしまいそうだ」→「だから消してくれ」という意味らしいのだが、しかし事情が知らない外国人が聞くと、単にその絵や文芸に不満があるかと誤解されかねない。しかし、英語は世界の覇権言語なので、外国人からの誤解を気にする必要も無い。日本人からすれば、まったく、英米人はうらやましい限りである。 この 勧誘の must を紹介しているインスパイア、ジーニアスも、コラム的に紹介しているだけである。（桐原ファクトのみ、本文で紹介。） :※ 昔から教育評論でよく言われる、英語教育の隠れた目的のひとつとして、誤解の恐れの少ない論理的な文章の書き方の教育を教える、という目的がある。文科省や国立大学などは、中立性などの理由で、「論理的な日本語の書き方はこうあるべきし」とは宣言できないので、仕方なく英文法など外国語を使って論理的な文章の書き方を教えようとしている、などとは昔はよく評論されたものである（もっとも、最近の英語教育では会話重視などで、そういう論理性の教育目的は雲散霧消してしまったが）。そういう論理的な文章の書き方の教育としては、勧誘 must やら上記例の「消してくれ」のような飛躍気味の用法は、嫌われるだろうから、大学入試などに勧誘の must などが出る可能性は低いかもしれない。 == 確信「ちがいない」 must の否定 == 「～にちがいない」という強い確認の意味での must の否定は、 cannot 「～はずがない」である（ジーニアス、インスパイア、青チャート）。 なぜそうかといわれても、そうだと決まってる。英米人がそういう使い方をしているので、合わせるしかない。 :※ これまた、あまり論理的でないので、おそらく入試では問われづらいだろう。たとえば桐原ファクトでは、must の項目では、確信の否定 cannot を無視しており、非紹介である。なお、桐原でも can の側で cannot「～はずがない」を説明しており、可能性 can の否定として cannot「～はずがない」 という用法を説明するというのが桐原ファクトの理論構成である。 cannot や can't と言った場合、単に「～できない」という可能性を否定するだけの用法もあるが（インスパイア　can側）、それとは別に「～のはずがない」という強めの感情的色彩をおびた「否定の確信」な意味の用法の場合もある（桐原ファクト、ジーニアス）。 o8yy5j9bky8bybjj4eta6tvzefifkng 205929 205928 2022-07-28T08:43:10Z すじにくシチュー 12058 wikitext text/x-wiki == must == === 勧誘 must === must には、強い勧誘を意味する用法もある（インスパイア、桐原ファクトブック、ジーニアス）。 You must ～. 「ぜひ～してください」「ぜひ～したほうがいい」 のような意味。 青チャートには書いていない。（あまり重要視してないのだろう。） 欧米人は、この手の、外国人には分かりづらい、やや飛躍気味の表現をすることもよくある。 :※ 飛躍気味とは、たとえば最近の俗語の例では、英米人の近年の若者などの用法で、すばらしい絵や文芸を見たときに、「その絵を消してくれ」なんていう表現も最近の英語では良く使われるという。どうやら「素晴らしすぎて、魅了されて、頭がおかしくなってしまいそうだ」→「だから消してくれ」という意味らしいのだが、しかし事情が知らない外国人が聞くと、単にその絵や文芸に不満があるかと誤解されかねない。しかし、英語は世界の覇権言語なので、外国人からの誤解を気にする必要も無い。日本人からすれば、まったく、英米人はうらやましい限りである。 この 勧誘の must を紹介しているインスパイア、ジーニアスも、コラム的に紹介しているだけである。（桐原ファクトのみ、本文で紹介。） :※ 昔から教育評論でよく言われる、英語教育の隠れた目的のひとつとして、誤解の恐れの少ない論理的な文章の書き方の教育を教える、という目的がある。文科省や国立大学などは、中立性などの理由で、「論理的な日本語の書き方はこうあるべきし」とは宣言できないので、仕方なく英文法など外国語を使って論理的な文章の書き方を教えようとしている、などとは昔はよく評論されたものである（もっとも、最近の英語教育では会話重視などで、そういう論理性の教育目的は雲散霧消してしまったが）。そういう論理的な文章の書き方の教育としては、勧誘 must やら上記例の「消してくれ」のような飛躍気味の用法は、嫌われるだろうから、大学入試などに勧誘の must などが出る可能性は低いかもしれない。 == 確信「ちがいない」 must の否定 == 「～にちがいない」という強い確認の意味での must の否定は、 cannot 「～はずがない」である（ジーニアス、インスパイア、青チャート）。 なぜそうかといわれても、そうだと決まってる。英米人がそういう使い方をしているので、合わせるしかない。 :※ これまた、あまり論理的でないので、おそらく入試では問われづらいだろう。たとえば桐原ファクトでは、must の項目では、確信の否定 cannot を無視しており、非紹介である。なお、桐原でも can の側で cannot「～はずがない」を説明しており、可能性 can の否定として cannot「～はずがない」 という用法を説明するというのが桐原ファクトの理論構成である。 cannot や can't と言った場合、単に「～できない」という可能性を否定するだけの用法もあるが（インスパイア　can側）、それとは別に「～のはずがない」という強めの感情的色彩をおびた「否定の確信」な意味の用法の場合もある（桐原ファクト、ジーニアス）。 == Can you ? == 英語では、相手に能力を直接聞くのは、失礼に当たると見なされている場合もある。 たとえば、 Can you speak Japanese? は、背景として、「あなたは日本語を話せないといけない」と思われることもある（インスパイア、ジーニアス）。このため、canを使わずに Do you speak Japanese? と聞くのが良いとされている（ジーニアス）。 can は、今後も通用する能力や可能性について言うので、単に一回だけのことに「昨日は～できた」みたいに言う場合には can や could を使わない（ジーニアス、青チャート）。 1回だけ「～できた」場合には、 be able to や 「managed to不定詞」 や succeed in ～ing などを使う（青チャート、インスパイア）。 また、とくに能力などを強調するのでなければ、単に過去形だけを使って1回だけできたことを表現してもいい（ジーニアス）。 なお、否定文や疑問文の場合は could を使っても良く、つまり couldn't や wasn't（または weren't） able to でもいい（インスパイア）。 1erksnpfmmmz5bc3tnhcawy5yp0ywgl 205930 205929 2022-07-28T08:48:53Z すじにくシチュー 12058 /* Can you ? */ wikitext text/x-wiki == must == === 勧誘 must === must には、強い勧誘を意味する用法もある（インスパイア、桐原ファクトブック、ジーニアス）。 You must ～. 「ぜひ～してください」「ぜひ～したほうがいい」 のような意味。 青チャートには書いていない。（あまり重要視してないのだろう。） 欧米人は、この手の、外国人には分かりづらい、やや飛躍気味の表現をすることもよくある。 :※ 飛躍気味とは、たとえば最近の俗語の例では、英米人の近年の若者などの用法で、すばらしい絵や文芸を見たときに、「その絵を消してくれ」なんていう表現も最近の英語では良く使われるという。どうやら「素晴らしすぎて、魅了されて、頭がおかしくなってしまいそうだ」→「だから消してくれ」という意味らしいのだが、しかし事情が知らない外国人が聞くと、単にその絵や文芸に不満があるかと誤解されかねない。しかし、英語は世界の覇権言語なので、外国人からの誤解を気にする必要も無い。日本人からすれば、まったく、英米人はうらやましい限りである。 この 勧誘の must を紹介しているインスパイア、ジーニアスも、コラム的に紹介しているだけである。（桐原ファクトのみ、本文で紹介。） :※ 昔から教育評論でよく言われる、英語教育の隠れた目的のひとつとして、誤解の恐れの少ない論理的な文章の書き方の教育を教える、という目的がある。文科省や国立大学などは、中立性などの理由で、「論理的な日本語の書き方はこうあるべきし」とは宣言できないので、仕方なく英文法など外国語を使って論理的な文章の書き方を教えようとしている、などとは昔はよく評論されたものである（もっとも、最近の英語教育では会話重視などで、そういう論理性の教育目的は雲散霧消してしまったが）。そういう論理的な文章の書き方の教育としては、勧誘 must やら上記例の「消してくれ」のような飛躍気味の用法は、嫌われるだろうから、大学入試などに勧誘の must などが出る可能性は低いかもしれない。 == 確信「ちがいない」 must の否定 == 「～にちがいない」という強い確認の意味での must の否定は、 cannot 「～はずがない」である（ジーニアス、インスパイア、青チャート）。 なぜそうかといわれても、そうだと決まってる。英米人がそういう使い方をしているので、合わせるしかない。 :※ これまた、あまり論理的でないので、おそらく入試では問われづらいだろう。たとえば桐原ファクトでは、must の項目では、確信の否定 cannot を無視しており、非紹介である。なお、桐原でも can の側で cannot「～はずがない」を説明しており、可能性 can の否定として cannot「～はずがない」 という用法を説明するというのが桐原ファクトの理論構成である。 cannot や can't と言った場合、単に「～できない」という可能性を否定するだけの用法もあるが（インスパイア　can側）、それとは別に「～のはずがない」という強めの感情的色彩をおびた「否定の確信」な意味の用法の場合もある（桐原ファクト、ジーニアス）。 == Can you ? == 英語では、相手に能力を直接聞くのは、失礼に当たると見なされている場合もある。 たとえば、 Can you speak Japanese? は、背景として、「あなたは日本語を話せないといけない」と思われることもある（インスパイア、ジーニアス）。このため、canを使わずに Do you speak Japanese? と聞くのが良いとされている（ジーニアス）。 また、派生的にか、可能性のcanは疑問文では、強めの疑いや、おどろきや当惑などの意味をもつこともよくある（青チャート、インスパイア）。参考書によくある典型的な例文だが Can the rumor be true? 「そのウワサは本当だろうか？」 という疑問文では、そのような、強めの疑いや、おどろきなどの意味がある。・ さて、can は、今後も通用する能力や可能性について言うので、単に一回だけのことに「昨日は～できた」みたいに言う場合には can や could を使わない（ジーニアス、青チャート）。 1回だけ「～できた」場合には、 be able to や 「managed to不定詞」 や succeed in ～ing などを使う（青チャート、インスパイア）。 また、とくに能力などを強調するのでなければ、単に過去形だけを使って1回だけできたことを表現してもいい（ジーニアス）。 なお、否定文や疑問文の場合は could を使っても良く、つまり couldn't や wasn't（または weren't） able to でもいい（インスパイア）。 dcx9upst3uihcwrrit3wr8f7jaxs4hp 205931 205930 2022-07-28T08:57:50Z すじにくシチュー 12058 /* Can you ? */ wikitext text/x-wiki == must == === 勧誘 must === must には、強い勧誘を意味する用法もある（インスパイア、桐原ファクトブック、ジーニアス）。 You must ～. 「ぜひ～してください」「ぜひ～したほうがいい」 のような意味。 青チャートには書いていない。（あまり重要視してないのだろう。） 欧米人は、この手の、外国人には分かりづらい、やや飛躍気味の表現をすることもよくある。 :※ 飛躍気味とは、たとえば最近の俗語の例では、英米人の近年の若者などの用法で、すばらしい絵や文芸を見たときに、「その絵を消してくれ」なんていう表現も最近の英語では良く使われるという。どうやら「素晴らしすぎて、魅了されて、頭がおかしくなってしまいそうだ」→「だから消してくれ」という意味らしいのだが、しかし事情が知らない外国人が聞くと、単にその絵や文芸に不満があるかと誤解されかねない。しかし、英語は世界の覇権言語なので、外国人からの誤解を気にする必要も無い。日本人からすれば、まったく、英米人はうらやましい限りである。 この 勧誘の must を紹介しているインスパイア、ジーニアスも、コラム的に紹介しているだけである。（桐原ファクトのみ、本文で紹介。） :※ 昔から教育評論でよく言われる、英語教育の隠れた目的のひとつとして、誤解の恐れの少ない論理的な文章の書き方の教育を教える、という目的がある。文科省や国立大学などは、中立性などの理由で、「論理的な日本語の書き方はこうあるべきし」とは宣言できないので、仕方なく英文法など外国語を使って論理的な文章の書き方を教えようとしている、などとは昔はよく評論されたものである（もっとも、最近の英語教育では会話重視などで、そういう論理性の教育目的は雲散霧消してしまったが）。そういう論理的な文章の書き方の教育としては、勧誘 must やら上記例の「消してくれ」のような飛躍気味の用法は、嫌われるだろうから、大学入試などに勧誘の must などが出る可能性は低いかもしれない。 == 確信「ちがいない」 must の否定 == 「～にちがいない」という強い確認の意味での must の否定は、 cannot 「～はずがない」である（ジーニアス、インスパイア、青チャート）。 なぜそうかといわれても、そうだと決まってる。英米人がそういう使い方をしているので、合わせるしかない。 :※ これまた、あまり論理的でないので、おそらく入試では問われづらいだろう。たとえば桐原ファクトでは、must の項目では、確信の否定 cannot を無視しており、非紹介である。なお、桐原でも can の側で cannot「～はずがない」を説明しており、可能性 can の否定として cannot「～はずがない」 という用法を説明するというのが桐原ファクトの理論構成である。 cannot や can't と言った場合、単に「～できない」という可能性を否定するだけの用法もあるが（インスパイア　can側）、それとは別に「～のはずがない」という強めの感情的色彩をおびた「否定の確信」な意味の用法の場合もある（桐原ファクト、ジーニアス）。 == Can you ? == 英語では、相手に能力を直接聞くのは、失礼に当たると見なされている場合もある。 たとえば、 Can you speak Japanese? は、背景として、「あなたは日本語を話せないといけない」と思われることもある（インスパイア、ジーニアス）。このため、canを使わずに Do you speak Japanese? と聞くのが良いとされている（ジーニアス）。 一方、話し手が自分の語学の能力を「私は～できます」と言う場合は、なるべく be able to よりも canを使うほうが謙遜気味で礼儀正しいとされており、つまり I can のほうが良いとされている（ジーニアス）。I のあとに be able to を使うと、英米では能力自慢のように聞こえるらしい（ジーニアス）。 can youが無礼なのに I can が礼儀正しいのは意味不明だが、しかし覇権国家の英米人がそう使い分けているので、英語学ではそう合わせるしかない。うらやましい。所詮、語学は暗記科目であり、「理屈と膏薬はどこにでもつく」（日本のことわざ）である。 また、派生的にか、可能性のcanは疑問文では、強めの疑いや、おどろきや当惑などの意味をもつこともよくある（青チャート、インスパイア）。参考書によくある典型的な例文だが Can the rumor be true? 「そのウワサは本当だろうか？」 という疑問文では、そのような、強めの疑いや、おどろきなどの意味がある。・ さて、can は、今後も通用する能力や可能性について言うので、単に一回だけのことに「昨日は～できた」みたいに言う場合には can や could を使わない（ジーニアス、青チャート）。 1回だけ「～できた」場合には、 be able to や 「managed to不定詞」 や succeed in ～ing などを使う（青チャート、インスパイア）。 また、とくに能力などを強調するのでなければ、単に過去形だけを使って1回だけできたことを表現してもいい（ジーニアス）。 なお、否定文や疑問文の場合は could を使っても良く、つまり couldn't や wasn't（または weren't） able to でもいい（インスパイア）。 ただし、こういう細かい使い分けよりも、入試に出るのは、構文 cannot help ～ing 「～せざるを得ない」 cannot help but ＋動詞の原型 「～せざるを得ない」 cannot but ＋動詞の原型 などだろう（インスパイア）。 90年代、こういう二重否定的な構文が（中学範囲ではなく）高校範囲だった過去がある。 cannot ～ too ○○ 「いくら～しすぎても○○しすぎることはない」 という反語的な表現も、90年代の典型的な高校英文法の範囲であった。 gfuv56j5lvjoxw86nh0gdle5lkyftyx 205932 205931 2022-07-28T09:03:06Z すじにくシチュー 12058 /* Can you ? */ ときに　～することがある」と好ましくない事を言う場合に can を使うことがある。 wikitext text/x-wiki == must == === 勧誘 must === must には、強い勧誘を意味する用法もある（インスパイア、桐原ファクトブック、ジーニアス）。 You must ～. 「ぜひ～してください」「ぜひ～したほうがいい」 のような意味。 青チャートには書いていない。（あまり重要視してないのだろう。） 欧米人は、この手の、外国人には分かりづらい、やや飛躍気味の表現をすることもよくある。 :※ 飛躍気味とは、たとえば最近の俗語の例では、英米人の近年の若者などの用法で、すばらしい絵や文芸を見たときに、「その絵を消してくれ」なんていう表現も最近の英語では良く使われるという。どうやら「素晴らしすぎて、魅了されて、頭がおかしくなってしまいそうだ」→「だから消してくれ」という意味らしいのだが、しかし事情が知らない外国人が聞くと、単にその絵や文芸に不満があるかと誤解されかねない。しかし、英語は世界の覇権言語なので、外国人からの誤解を気にする必要も無い。日本人からすれば、まったく、英米人はうらやましい限りである。 この 勧誘の must を紹介しているインスパイア、ジーニアスも、コラム的に紹介しているだけである。（桐原ファクトのみ、本文で紹介。） :※ 昔から教育評論でよく言われる、英語教育の隠れた目的のひとつとして、誤解の恐れの少ない論理的な文章の書き方の教育を教える、という目的がある。文科省や国立大学などは、中立性などの理由で、「論理的な日本語の書き方はこうあるべきし」とは宣言できないので、仕方なく英文法など外国語を使って論理的な文章の書き方を教えようとしている、などとは昔はよく評論されたものである（もっとも、最近の英語教育では会話重視などで、そういう論理性の教育目的は雲散霧消してしまったが）。そういう論理的な文章の書き方の教育としては、勧誘 must やら上記例の「消してくれ」のような飛躍気味の用法は、嫌われるだろうから、大学入試などに勧誘の must などが出る可能性は低いかもしれない。 == 確信「ちがいない」 must の否定 == 「～にちがいない」という強い確認の意味での must の否定は、 cannot 「～はずがない」である（ジーニアス、インスパイア、青チャート）。 なぜそうかといわれても、そうだと決まってる。英米人がそういう使い方をしているので、合わせるしかない。 :※ これまた、あまり論理的でないので、おそらく入試では問われづらいだろう。たとえば桐原ファクトでは、must の項目では、確信の否定 cannot を無視しており、非紹介である。なお、桐原でも can の側で cannot「～はずがない」を説明しており、可能性 can の否定として cannot「～はずがない」 という用法を説明するというのが桐原ファクトの理論構成である。 cannot や can't と言った場合、単に「～できない」という可能性を否定するだけの用法もあるが（インスパイア　can側）、それとは別に「～のはずがない」という強めの感情的色彩をおびた「否定の確信」な意味の用法の場合もある（桐原ファクト、ジーニアス）。 == Can you ? == 英語では、相手に能力を直接聞くのは、失礼に当たると見なされている場合もある。 たとえば、 Can you speak Japanese? は、背景として、「あなたは日本語を話せないといけない」と思われることもある（インスパイア、ジーニアス）。このため、canを使わずに Do you speak Japanese? と聞くのが良いとされている（ジーニアス）。 一方、話し手が自分の語学の能力を「私は～できます」と言う場合は、なるべく be able to よりも canを使うほうが謙遜気味で礼儀正しいとされており、つまり I can のほうが良いとされている（ジーニアス）。I のあとに be able to を使うと、英米では能力自慢のように聞こえるらしい（ジーニアス）。 can youが無礼なのに I can が礼儀正しいのは意味不明だが、しかし覇権国家の英米人がそう使い分けているので、英語学ではそう合わせるしかない。うらやましい。所詮、語学は暗記科目であり、「理屈と膏薬はどこにでもつく」（日本のことわざ）である。 また、派生的にか、可能性のcanは疑問文では、強めの疑いや、おどろきや当惑などの意味をもつこともよくある（青チャート、インスパイア）。参考書によくある典型的な例文だが Can the rumor be true? 「そのウワサは本当だろうか？」 という疑問文では、そのような、強めの疑いや、おどろきなどの意味がある。・ さて、can は、今後も通用する能力や可能性について言うので、単に一回だけのことに「昨日は～できた」みたいに言う場合には can や could を使わない（ジーニアス、青チャート）。 1回だけ「～できた」場合には、 be able to や 「managed to不定詞」 や succeed in ～ing などを使う（青チャート、インスパイア）。 また、とくに能力などを強調するのでなければ、単に過去形だけを使って1回だけできたことを表現してもいい（ジーニアス）。 なお、否定文や疑問文の場合は could を使っても良く、つまり couldn't や wasn't（または weren't） able to でもいい（インスパイア）。 ただし、こういう細かい使い分けよりも、入試に出るのは、構文 cannot help ～ing 「～せざるを得ない」 cannot help but ＋動詞の原型 「～せざるを得ない」 cannot but ＋動詞の原型 などだろう（インスパイア）。 90年代、こういう二重否定的な構文が（中学範囲ではなく）高校範囲だった過去がある。 cannot ～ too ○○ 「いくら～しすぎても○○しすぎることはない」 という反語的な表現も、90年代の典型的な高校英文法の範囲であった。 そのほか、「ときに　～することがある」と好ましくない事を言う場合に can を使うことがある。ジーニアスいわく「風邪は時に重い病気につながることがある」とか、青チャートいわく「そういう事故はときどき起こりうるものだ」で can を使っている。 だが、これとは逆に思える用法もインスパイアにあり、「can はもともと備わっている能力を表す」として「be able to は一時的な能力を表す」などという用法もある。 ※ このように、助動詞まわりは、あまり規則的ではなく、またやや口語的であり、あまり日本の大学入試対策としては深入りする必要が無いだろう。上述したが cannot help ～ ing のような構文を覚えることを優先すべきである。 jkfezt6uz55pcslyv1rq9rzpi6d1yv7 205933 205932 2022-07-28T09:04:21Z すじにくシチュー 12058 /* Can you ? */ wikitext text/x-wiki == must == === 勧誘 must === must には、強い勧誘を意味する用法もある（インスパイア、桐原ファクトブック、ジーニアス）。 You must ～. 「ぜひ～してください」「ぜひ～したほうがいい」 のような意味。 青チャートには書いていない。（あまり重要視してないのだろう。） 欧米人は、この手の、外国人には分かりづらい、やや飛躍気味の表現をすることもよくある。 :※ 飛躍気味とは、たとえば最近の俗語の例では、英米人の近年の若者などの用法で、すばらしい絵や文芸を見たときに、「その絵を消してくれ」なんていう表現も最近の英語では良く使われるという。どうやら「素晴らしすぎて、魅了されて、頭がおかしくなってしまいそうだ」→「だから消してくれ」という意味らしいのだが、しかし事情が知らない外国人が聞くと、単にその絵や文芸に不満があるかと誤解されかねない。しかし、英語は世界の覇権言語なので、外国人からの誤解を気にする必要も無い。日本人からすれば、まったく、英米人はうらやましい限りである。 この 勧誘の must を紹介しているインスパイア、ジーニアスも、コラム的に紹介しているだけである。（桐原ファクトのみ、本文で紹介。） :※ 昔から教育評論でよく言われる、英語教育の隠れた目的のひとつとして、誤解の恐れの少ない論理的な文章の書き方の教育を教える、という目的がある。文科省や国立大学などは、中立性などの理由で、「論理的な日本語の書き方はこうあるべきし」とは宣言できないので、仕方なく英文法など外国語を使って論理的な文章の書き方を教えようとしている、などとは昔はよく評論されたものである（もっとも、最近の英語教育では会話重視などで、そういう論理性の教育目的は雲散霧消してしまったが）。そういう論理的な文章の書き方の教育としては、勧誘 must やら上記例の「消してくれ」のような飛躍気味の用法は、嫌われるだろうから、大学入試などに勧誘の must などが出る可能性は低いかもしれない。 == 確信「ちがいない」 must の否定 == 「～にちがいない」という強い確認の意味での must の否定は、 cannot 「～はずがない」である（ジーニアス、インスパイア、青チャート）。 なぜそうかといわれても、そうだと決まってる。英米人がそういう使い方をしているので、合わせるしかない。 :※ これまた、あまり論理的でないので、おそらく入試では問われづらいだろう。たとえば桐原ファクトでは、must の項目では、確信の否定 cannot を無視しており、非紹介である。なお、桐原でも can の側で cannot「～はずがない」を説明しており、可能性 can の否定として cannot「～はずがない」 という用法を説明するというのが桐原ファクトの理論構成である。 cannot や can't と言った場合、単に「～できない」という可能性を否定するだけの用法もあるが（インスパイア　can側）、それとは別に「～のはずがない」という強めの感情的色彩をおびた「否定の確信」な意味の用法の場合もある（桐原ファクト、ジーニアス）。 == Can you ? == 英語では、相手に能力を直接聞くのは、失礼に当たると見なされている場合もある。 たとえば、 Can you speak Japanese? は、背景として、「あなたは日本語を話せないといけない」と思われることもある（インスパイア、ジーニアス）。このため、canを使わずに Do you speak Japanese? と聞くのが良いとされている（ジーニアス）。 一方、話し手が自分の語学の能力を「私は～できます」と言う場合は、なるべく be able to よりも canを使うほうが謙遜気味で礼儀正しいとされており、つまり I can のほうが良いとされている（ジーニアス）。I のあとに be able to を使うと、英米では能力自慢のように聞こえるらしい（ジーニアス）。 can youが無礼なのに I can が礼儀正しいのは意味不明だが、しかし覇権国家の英米人がそう使い分けているので、英語学ではそう合わせるしかない。うらやましい。所詮、語学は暗記科目であり、「理屈と膏薬はどこにでもつく」（日本のことわざ）である。 また、派生的にか、可能性のcanは疑問文では、強めの疑いや、おどろきや当惑などの意味をもつこともよくある（青チャート、インスパイア）。参考書によくある典型的な例文だが Can the rumor be true? 「そのウワサは本当だろうか？」 という疑問文では、そのような、強めの疑いや、おどろきなどの意味がある。・ さて、can は、今後も通用する能力や可能性について言うので、単に一回だけのことに「昨日は～できた」みたいに言う場合には can や could を使わない（ジーニアス、青チャート）。 1回だけ「～できた」場合には、 be able to や 「managed to不定詞」 や succeed in ～ing などを使う（青チャート、インスパイア）。 また、とくに能力などを強調するのでなければ、単に過去形だけを使って1回だけできたことを表現してもいい（ジーニアス）。 なお、否定文や疑問文の場合は could を使っても良く、つまり couldn't や wasn't（または weren't） able to でもいい（インスパイア）。 ただし、こういう細かい使い分けよりも、入試に出るのは、構文 cannot help ～ing 「～せざるを得ない」 cannot help but ＋動詞の原型 「～せざるを得ない」 cannot but ＋動詞の原型 などだろう（インスパイア、桐原ファクトブック）。 90年代、こういう二重否定的な構文が（中学範囲ではなく）高校範囲だった過去がある。 cannot ～ too ○○ 「いくら～しすぎても○○しすぎることはない」 という反語的な表現も、90年代の典型的な高校英文法の範囲であった。 そのほか、「ときに　～することがある」と好ましくない事を言う場合に can を使うことがある。ジーニアスいわく「風邪は時に重い病気につながることがある」とか、青チャートいわく「そういう事故はときどき起こりうるものだ」で can を使っている。 だが、これとは逆に思える用法もインスパイアにあり、「can はもともと備わっている能力を表す」として「be able to は一時的な能力を表す」などという用法もある。 ※ このように、助動詞まわりは、あまり規則的ではなく、またやや口語的であり、あまり日本の大学入試対策としては深入りする必要が無いだろう。上述したが cannot help ～ ing のような構文を覚えることを優先すべきである。 pb5dabdv5i9csudczoa8qeg0q2j71c2 205934 205933 2022-07-28T09:20:00Z すじにくシチュー 12058 wikitext text/x-wiki == must == === 勧誘 must === must には、強い勧誘を意味する用法もある（インスパイア、桐原ファクトブック、ジーニアス）。 You must ～. 「ぜひ～してください」「ぜひ～したほうがいい」 のような意味。 青チャートには書いていない。（あまり重要視してないのだろう。） 欧米人は、この手の、外国人には分かりづらい、やや飛躍気味の表現をすることもよくある。 :※ 飛躍気味とは、たとえば最近の俗語の例では、英米人の近年の若者などの用法で、すばらしい絵や文芸を見たときに、「その絵を消してくれ」なんていう表現も最近の英語では良く使われるという。どうやら「素晴らしすぎて、魅了されて、頭がおかしくなってしまいそうだ」→「だから消してくれ」という意味らしいのだが、しかし事情が知らない外国人が聞くと、単にその絵や文芸に不満があるかと誤解されかねない。しかし、英語は世界の覇権言語なので、外国人からの誤解を気にする必要も無い。日本人からすれば、まったく、英米人はうらやましい限りである。 この 勧誘の must を紹介しているインスパイア、ジーニアスも、コラム的に紹介しているだけである。（桐原ファクトのみ、本文で紹介。） :※ 昔から教育評論でよく言われる、英語教育の隠れた目的のひとつとして、誤解の恐れの少ない論理的な文章の書き方の教育を教える、という目的がある。文科省や国立大学などは、中立性などの理由で、「論理的な日本語の書き方はこうあるべきし」とは宣言できないので、仕方なく英文法など外国語を使って論理的な文章の書き方を教えようとしている、などとは昔はよく評論されたものである（もっとも、最近の英語教育では会話重視などで、そういう論理性の教育目的は雲散霧消してしまったが）。そういう論理的な文章の書き方の教育としては、勧誘 must やら上記例の「消してくれ」のような飛躍気味の用法は、嫌われるだろうから、大学入試などに勧誘の must などが出る可能性は低いかもしれない。 == 確信「ちがいない」 must の否定 == 「～にちがいない」という強い確認の意味での must の否定は、 cannot 「～はずがない」である（ジーニアス、インスパイア、青チャート）。 なぜそうかといわれても、そうだと決まってる。英米人がそういう使い方をしているので、合わせるしかない。 :※ これまた、あまり論理的でないので、おそらく入試では問われづらいだろう。たとえば桐原ファクトでは、must の項目では、確信の否定 cannot を無視しており、非紹介である。なお、桐原でも can の側で cannot「～はずがない」を説明しており、可能性 can の否定として cannot「～はずがない」 という用法を説明するというのが桐原ファクトの理論構成である。 cannot や can't と言った場合、単に「～できない」という可能性を否定するだけの用法もあるが（インスパイア　can側）、それとは別に「～のはずがない」という強めの感情的色彩をおびた「否定の確信」な意味の用法の場合もある（桐原ファクト、ジーニアス）。 == Can you ? == 英語では、相手に能力を直接聞くのは、失礼に当たると見なされている場合もある。 たとえば、 Can you speak Japanese? は、背景として、「あなたは日本語を話せないといけない」と思われることもある（インスパイア、ジーニアス）。このため、canを使わずに Do you speak Japanese? と聞くのが良いとされている（ジーニアス）。 一方、話し手が自分の語学の能力を「私は～できます」と言う場合は、なるべく be able to よりも canを使うほうが謙遜気味で礼儀正しいとされており、つまり I can のほうが良いとされている（ジーニアス）。I のあとに be able to を使うと、英米では能力自慢のように聞こえるらしい（ジーニアス）。 can youが無礼なのに I can が礼儀正しいのは意味不明だが、しかし覇権国家の英米人がそう使い分けているので、英語学ではそう合わせるしかない。うらやましい。所詮、語学は暗記科目であり、「理屈と膏薬はどこにでもつく」（日本のことわざ）である。 また、派生的にか、可能性のcanは疑問文では、強めの疑いや、おどろきや当惑などの意味をもつこともよくある（青チャート、インスパイア）。参考書によくある典型的な例文だが Can the rumor be true? 「そのウワサは本当だろうか？」 という疑問文では、そのような、強めの疑いや、おどろきなどの意味がある。・ さて、can は、今後も通用する能力や可能性について言うので、単に一回だけのことに「昨日は～できた」みたいに言う場合には can や could を使わない（ジーニアス、青チャート）。 1回だけ「～できた」場合には、 be able to や 「managed to不定詞」 や succeed in ～ing などを使う（青チャート、インスパイア）。 また、とくに能力などを強調するのでなければ、単に過去形だけを使って1回だけできたことを表現してもいい（ジーニアス）。 なお、否定文や疑問文の場合は could を使っても良く、つまり couldn't や wasn't（または weren't） able to でもいい（インスパイア）。 ただし、こういう細かい使い分けよりも、入試に出るのは、構文 cannot help ～ing 「～せざるを得ない」 cannot help but ＋動詞の原型 「～せざるを得ない」 cannot but ＋動詞の原型 などだろう（インスパイア、桐原ファクトブック）。 90年代、こういう二重否定的な構文が（中学範囲ではなく）高校範囲だった過去がある。 cannot ～ too ○○ 「いくら～しすぎても○○しすぎることはない」 という反語的な表現も、90年代の典型的な高校英文法の範囲であった。 そのほか、「ときに　～することがある」と好ましくない事を言う場合に can を使うことがある。ジーニアスいわく「風邪は時に重い病気につながることがある」とか、青チャートいわく「そういう事故はときどき起こりうるものだ」で can を使っている。 だが、これとは逆に思える用法もインスパイアにあり、「can はもともと備わっている能力を表す」として「be able to は一時的な能力を表す」などという用法もある。 ※ このように、助動詞まわりは、あまり規則的ではなく、またやや口語的であり、あまり日本の大学入試対策としては深入りする必要が無いだろう。上述したが cannot help ～ ing のような構文を覚えることを優先すべきである。 == 助動詞 need == 本動詞 need とは別に、助動詞 need というのがある。 助動詞 need は主にイギリス英語である。 参考書では平叙文に助動詞 need が使われることもあるが（ジーニアス）、しかし実際の英米では疑問文と否定文でのみ助動詞 need が使われるのが一般的である（青チャート、桐原ファクト）。 このような制限が助動詞 need にあるため、実のところ、あまり信用頻度は高くない、・・・というのが桐原ファクトの見解。 また、助動詞 need に過去形は無い（青チャ、インスパ）。また、主語が三人称単数でも、助動詞 need には sはつかず、needのまま（青チャ）。 もし、過去の必要性について言いたい場合、単に、本動詞 「need to不定詞」を使えばいい（ジーニアス、青チャ、インスパイア）。 なお、本動詞 need の否定文や疑問文は、単に中学英文法と同様に I didn't need to 不定詞 や Did you need to 不定詞 ? を使えばいいだけである。 cemfmpgu5j7s9phdes228nddga2ycyg 205935 205934 2022-07-28T09:20:14Z すじにくシチュー 12058 /* 助動詞 need */ wikitext text/x-wiki == must == === 勧誘 must === must には、強い勧誘を意味する用法もある（インスパイア、桐原ファクトブック、ジーニアス）。 You must ～. 「ぜひ～してください」「ぜひ～したほうがいい」 のような意味。 青チャートには書いていない。（あまり重要視してないのだろう。） 欧米人は、この手の、外国人には分かりづらい、やや飛躍気味の表現をすることもよくある。 :※ 飛躍気味とは、たとえば最近の俗語の例では、英米人の近年の若者などの用法で、すばらしい絵や文芸を見たときに、「その絵を消してくれ」なんていう表現も最近の英語では良く使われるという。どうやら「素晴らしすぎて、魅了されて、頭がおかしくなってしまいそうだ」→「だから消してくれ」という意味らしいのだが、しかし事情が知らない外国人が聞くと、単にその絵や文芸に不満があるかと誤解されかねない。しかし、英語は世界の覇権言語なので、外国人からの誤解を気にする必要も無い。日本人からすれば、まったく、英米人はうらやましい限りである。 この 勧誘の must を紹介しているインスパイア、ジーニアスも、コラム的に紹介しているだけである。（桐原ファクトのみ、本文で紹介。） :※ 昔から教育評論でよく言われる、英語教育の隠れた目的のひとつとして、誤解の恐れの少ない論理的な文章の書き方の教育を教える、という目的がある。文科省や国立大学などは、中立性などの理由で、「論理的な日本語の書き方はこうあるべきし」とは宣言できないので、仕方なく英文法など外国語を使って論理的な文章の書き方を教えようとしている、などとは昔はよく評論されたものである（もっとも、最近の英語教育では会話重視などで、そういう論理性の教育目的は雲散霧消してしまったが）。そういう論理的な文章の書き方の教育としては、勧誘 must やら上記例の「消してくれ」のような飛躍気味の用法は、嫌われるだろうから、大学入試などに勧誘の must などが出る可能性は低いかもしれない。 == 確信「ちがいない」 must の否定 == 「～にちがいない」という強い確認の意味での must の否定は、 cannot 「～はずがない」である（ジーニアス、インスパイア、青チャート）。 なぜそうかといわれても、そうだと決まってる。英米人がそういう使い方をしているので、合わせるしかない。 :※ これまた、あまり論理的でないので、おそらく入試では問われづらいだろう。たとえば桐原ファクトでは、must の項目では、確信の否定 cannot を無視しており、非紹介である。なお、桐原でも can の側で cannot「～はずがない」を説明しており、可能性 can の否定として cannot「～はずがない」 という用法を説明するというのが桐原ファクトの理論構成である。 cannot や can't と言った場合、単に「～できない」という可能性を否定するだけの用法もあるが（インスパイア　can側）、それとは別に「～のはずがない」という強めの感情的色彩をおびた「否定の確信」な意味の用法の場合もある（桐原ファクト、ジーニアス）。 == Can you ? == 英語では、相手に能力を直接聞くのは、失礼に当たると見なされている場合もある。 たとえば、 Can you speak Japanese? は、背景として、「あなたは日本語を話せないといけない」と思われることもある（インスパイア、ジーニアス）。このため、canを使わずに Do you speak Japanese? と聞くのが良いとされている（ジーニアス）。 一方、話し手が自分の語学の能力を「私は～できます」と言う場合は、なるべく be able to よりも canを使うほうが謙遜気味で礼儀正しいとされており、つまり I can のほうが良いとされている（ジーニアス）。I のあとに be able to を使うと、英米では能力自慢のように聞こえるらしい（ジーニアス）。 can youが無礼なのに I can が礼儀正しいのは意味不明だが、しかし覇権国家の英米人がそう使い分けているので、英語学ではそう合わせるしかない。うらやましい。所詮、語学は暗記科目であり、「理屈と膏薬はどこにでもつく」（日本のことわざ）である。 また、派生的にか、可能性のcanは疑問文では、強めの疑いや、おどろきや当惑などの意味をもつこともよくある（青チャート、インスパイア）。参考書によくある典型的な例文だが Can the rumor be true? 「そのウワサは本当だろうか？」 という疑問文では、そのような、強めの疑いや、おどろきなどの意味がある。・ さて、can は、今後も通用する能力や可能性について言うので、単に一回だけのことに「昨日は～できた」みたいに言う場合には can や could を使わない（ジーニアス、青チャート）。 1回だけ「～できた」場合には、 be able to や 「managed to不定詞」 や succeed in ～ing などを使う（青チャート、インスパイア）。 また、とくに能力などを強調するのでなければ、単に過去形だけを使って1回だけできたことを表現してもいい（ジーニアス）。 なお、否定文や疑問文の場合は could を使っても良く、つまり couldn't や wasn't（または weren't） able to でもいい（インスパイア）。 ただし、こういう細かい使い分けよりも、入試に出るのは、構文 cannot help ～ing 「～せざるを得ない」 cannot help but ＋動詞の原型 「～せざるを得ない」 cannot but ＋動詞の原型 などだろう（インスパイア、桐原ファクトブック）。 90年代、こういう二重否定的な構文が（中学範囲ではなく）高校範囲だった過去がある。 cannot ～ too ○○ 「いくら～しすぎても○○しすぎることはない」 という反語的な表現も、90年代の典型的な高校英文法の範囲であった。 そのほか、「ときに　～することがある」と好ましくない事を言う場合に can を使うことがある。ジーニアスいわく「風邪は時に重い病気につながることがある」とか、青チャートいわく「そういう事故はときどき起こりうるものだ」で can を使っている。 だが、これとは逆に思える用法もインスパイアにあり、「can はもともと備わっている能力を表す」として「be able to は一時的な能力を表す」などという用法もある。 ※ このように、助動詞まわりは、あまり規則的ではなく、またやや口語的であり、あまり日本の大学入試対策としては深入りする必要が無いだろう。上述したが cannot help ～ ing のような構文を覚えることを優先すべきである。 == 助動詞 need == 本動詞 need とは別に、助動詞 need というのがある。 助動詞 need は主にイギリス英語である。 参考書では平叙文に助動詞 need が使われることもあるが（ジーニアス）、しかし実際の英米では疑問文と否定文でのみ助動詞 need が使われるのが一般的である（青チャート、桐原ファクト）。 このような制限が助動詞 need にあるため、実のところ、あまり信用頻度は高くない、・・・というのが桐原ファクトの見解。 また、助動詞 need に過去形は無い（青チャ、インスパ）。また、主語が三人称単数でも、助動詞 need には sはつかず、needのまま（青チャ）。 もし、過去の必要性について言いたい場合、単に、本動詞 「need to不定詞」を使えばいい（ジーニアス、青チャ、インスパイア）。 なお、本動詞 need の否定文や疑問文は、単に中学英文法と同様に I didn't need to 不定詞 や Did you need to 不定詞 ? を使えばいいだけである。 pobvmec8vp3z9088cq060vgfbf1caq3 205936 205935 2022-07-28T09:35:56Z すじにくシチュー 12058 == dare == wikitext text/x-wiki == must == === 勧誘 must === must には、強い勧誘を意味する用法もある（インスパイア、桐原ファクトブック、ジーニアス）。 You must ～. 「ぜひ～してください」「ぜひ～したほうがいい」 のような意味。 青チャートには書いていない。（あまり重要視してないのだろう。） 欧米人は、この手の、外国人には分かりづらい、やや飛躍気味の表現をすることもよくある。 :※ 飛躍気味とは、たとえば最近の俗語の例では、英米人の近年の若者などの用法で、すばらしい絵や文芸を見たときに、「その絵を消してくれ」なんていう表現も最近の英語では良く使われるという。どうやら「素晴らしすぎて、魅了されて、頭がおかしくなってしまいそうだ」→「だから消してくれ」という意味らしいのだが、しかし事情が知らない外国人が聞くと、単にその絵や文芸に不満があるかと誤解されかねない。しかし、英語は世界の覇権言語なので、外国人からの誤解を気にする必要も無い。日本人からすれば、まったく、英米人はうらやましい限りである。 この 勧誘の must を紹介しているインスパイア、ジーニアスも、コラム的に紹介しているだけである。（桐原ファクトのみ、本文で紹介。） :※ 昔から教育評論でよく言われる、英語教育の隠れた目的のひとつとして、誤解の恐れの少ない論理的な文章の書き方の教育を教える、という目的がある。文科省や国立大学などは、中立性などの理由で、「論理的な日本語の書き方はこうあるべきし」とは宣言できないので、仕方なく英文法など外国語を使って論理的な文章の書き方を教えようとしている、などとは昔はよく評論されたものである（もっとも、最近の英語教育では会話重視などで、そういう論理性の教育目的は雲散霧消してしまったが）。そういう論理的な文章の書き方の教育としては、勧誘 must やら上記例の「消してくれ」のような飛躍気味の用法は、嫌われるだろうから、大学入試などに勧誘の must などが出る可能性は低いかもしれない。 == 確信「ちがいない」 must の否定 == 「～にちがいない」という強い確認の意味での must の否定は、 cannot 「～はずがない」である（ジーニアス、インスパイア、青チャート）。 なぜそうかといわれても、そうだと決まってる。英米人がそういう使い方をしているので、合わせるしかない。 :※ これまた、あまり論理的でないので、おそらく入試では問われづらいだろう。たとえば桐原ファクトでは、must の項目では、確信の否定 cannot を無視しており、非紹介である。なお、桐原でも can の側で cannot「～はずがない」を説明しており、可能性 can の否定として cannot「～はずがない」 という用法を説明するというのが桐原ファクトの理論構成である。 cannot や can't と言った場合、単に「～できない」という可能性を否定するだけの用法もあるが（インスパイア　can側）、それとは別に「～のはずがない」という強めの感情的色彩をおびた「否定の確信」な意味の用法の場合もある（桐原ファクト、ジーニアス）。 == Can you ? == 英語では、相手に能力を直接聞くのは、失礼に当たると見なされている場合もある。 たとえば、 Can you speak Japanese? は、背景として、「あなたは日本語を話せないといけない」と思われることもある（インスパイア、ジーニアス）。このため、canを使わずに Do you speak Japanese? と聞くのが良いとされている（ジーニアス）。 一方、話し手が自分の語学の能力を「私は～できます」と言う場合は、なるべく be able to よりも canを使うほうが謙遜気味で礼儀正しいとされており、つまり I can のほうが良いとされている（ジーニアス）。I のあとに be able to を使うと、英米では能力自慢のように聞こえるらしい（ジーニアス）。 can youが無礼なのに I can が礼儀正しいのは意味不明だが、しかし覇権国家の英米人がそう使い分けているので、英語学ではそう合わせるしかない。うらやましい。所詮、語学は暗記科目であり、「理屈と膏薬はどこにでもつく」（日本のことわざ）である。 また、派生的にか、可能性のcanは疑問文では、強めの疑いや、おどろきや当惑などの意味をもつこともよくある（青チャート、インスパイア）。参考書によくある典型的な例文だが Can the rumor be true? 「そのウワサは本当だろうか？」 という疑問文では、そのような、強めの疑いや、おどろきなどの意味がある。・ さて、can は、今後も通用する能力や可能性について言うので、単に一回だけのことに「昨日は～できた」みたいに言う場合には can や could を使わない（ジーニアス、青チャート）。 1回だけ「～できた」場合には、 be able to や 「managed to不定詞」 や succeed in ～ing などを使う（青チャート、インスパイア）。 また、とくに能力などを強調するのでなければ、単に過去形だけを使って1回だけできたことを表現してもいい（ジーニアス）。 なお、否定文や疑問文の場合は could を使っても良く、つまり couldn't や wasn't（または weren't） able to でもいい（インスパイア）。 ただし、こういう細かい使い分けよりも、入試に出るのは、構文 cannot help ～ing 「～せざるを得ない」 cannot help but ＋動詞の原型 「～せざるを得ない」 cannot but ＋動詞の原型 などだろう（インスパイア、桐原ファクトブック）。 90年代、こういう二重否定的な構文が（中学範囲ではなく）高校範囲だった過去がある。 cannot ～ too ○○ 「いくら～しすぎても○○しすぎることはない」 という反語的な表現も、90年代の典型的な高校英文法の範囲であった。 そのほか、「ときに　～することがある」と好ましくない事を言う場合に can を使うことがある。ジーニアスいわく「風邪は時に重い病気につながることがある」とか、青チャートいわく「そういう事故はときどき起こりうるものだ」で can を使っている。 だが、これとは逆に思える用法もインスパイアにあり、「can はもともと備わっている能力を表す」として「be able to は一時的な能力を表す」などという用法もある。 ※ このように、助動詞まわりは、あまり規則的ではなく、またやや口語的であり、あまり日本の大学入試対策としては深入りする必要が無いだろう。上述したが cannot help ～ ing のような構文を覚えることを優先すべきである。 == 助動詞 need == 本動詞 need とは別に、助動詞 need というのがあり、 「need ＋動詞の原型」の形で使う。 助動詞 need は主にイギリス英語である。 参考書では平叙文に助動詞 need が使われることもあるが（ジーニアス）、しかし実際の英米では疑問文と否定文でのみ助動詞 need が使われるのが一般的である（青チャート、桐原ファクト）。 このような制限が助動詞 need にあるため、実のところ、あまり信用頻度は高くない、・・・というのが桐原ファクトの見解。 助動詞 need の否定形は need not または needn't であり（青チャ－ト）、つまり「 need not ＋動詞の原型」のような形になる。 また、助動詞 need に過去形は無い（青チャ、インスパ）。また、主語が三人称単数でも、助動詞 need には sはつかず、needのまま（青チャ）。 もし、過去の必要性について言いたい場合、単に、本動詞 「need to不定詞」を使えばいい（ジーニアス、青チャ、インスパイア）。 なお、本動詞 need の否定文や疑問文は、単に中学英文法と同様に I didn't need to 不定詞 や Did you need to 不定詞 ? を使えばいいだけである。 なお、完了形との組み合わせ「 need not have ＋過去分詞」だと、「～する必要はなかったのに」という意味になる（ジーニアス）。 == dare == 助動詞としては、 How dare say ～？　「よくも～できたものだね」 という苛立ち（いらだち）をあらわす。 I dare say ～. 「たぶん～だろう」「おそらく～だろう」 sayのあとに接続詞 that は続かない（インスパイア）。 I daresay ～ という一語でdareとsayを縮めた言い回しもある（インスパイア、ブレイクスルー）。 dare の用法は、あまり論理的ではない。ほか、助動詞 dareに過去形 dared もあるとされているが、現代ではマレ（青チャート）。 そのほか、本動詞としての dare の用法があり、上記２つの「How dare」「I dare say（または daresay）」慣用表現以外の場合では、本動詞としてdareをつかうことのほうが一般的であり（ジーニアス）、 He dares（または dared） to ～ 「彼はずうずうしくも～する（した）」 のように使うこともある（青チャ）。 aly8dfxp9fy0r2v09exwydmlumnyqpw 205937 205936 2022-07-28T09:46:11Z すじにくシチュー 12058 /* dare */ wikitext text/x-wiki == must == === 勧誘 must === must には、強い勧誘を意味する用法もある（インスパイア、桐原ファクトブック、ジーニアス）。 You must ～. 「ぜひ～してください」「ぜひ～したほうがいい」 のような意味。 青チャートには書いていない。（あまり重要視してないのだろう。） 欧米人は、この手の、外国人には分かりづらい、やや飛躍気味の表現をすることもよくある。 :※ 飛躍気味とは、たとえば最近の俗語の例では、英米人の近年の若者などの用法で、すばらしい絵や文芸を見たときに、「その絵を消してくれ」なんていう表現も最近の英語では良く使われるという。どうやら「素晴らしすぎて、魅了されて、頭がおかしくなってしまいそうだ」→「だから消してくれ」という意味らしいのだが、しかし事情が知らない外国人が聞くと、単にその絵や文芸に不満があるかと誤解されかねない。しかし、英語は世界の覇権言語なので、外国人からの誤解を気にする必要も無い。日本人からすれば、まったく、英米人はうらやましい限りである。 この 勧誘の must を紹介しているインスパイア、ジーニアスも、コラム的に紹介しているだけである。（桐原ファクトのみ、本文で紹介。） :※ 昔から教育評論でよく言われる、英語教育の隠れた目的のひとつとして、誤解の恐れの少ない論理的な文章の書き方の教育を教える、という目的がある。文科省や国立大学などは、中立性などの理由で、「論理的な日本語の書き方はこうあるべきし」とは宣言できないので、仕方なく英文法など外国語を使って論理的な文章の書き方を教えようとしている、などとは昔はよく評論されたものである（もっとも、最近の英語教育では会話重視などで、そういう論理性の教育目的は雲散霧消してしまったが）。そういう論理的な文章の書き方の教育としては、勧誘 must やら上記例の「消してくれ」のような飛躍気味の用法は、嫌われるだろうから、大学入試などに勧誘の must などが出る可能性は低いかもしれない。 == 確信「ちがいない」 must の否定 == 「～にちがいない」という強い確認の意味での must の否定は、 cannot 「～はずがない」である（ジーニアス、インスパイア、青チャート）。 なぜそうかといわれても、そうだと決まってる。英米人がそういう使い方をしているので、合わせるしかない。 :※ これまた、あまり論理的でないので、おそらく入試では問われづらいだろう。たとえば桐原ファクトでは、must の項目では、確信の否定 cannot を無視しており、非紹介である。なお、桐原でも can の側で cannot「～はずがない」を説明しており、可能性 can の否定として cannot「～はずがない」 という用法を説明するというのが桐原ファクトの理論構成である。 cannot や can't と言った場合、単に「～できない」という可能性を否定するだけの用法もあるが（インスパイア　can側）、それとは別に「～のはずがない」という強めの感情的色彩をおびた「否定の確信」な意味の用法の場合もある（桐原ファクト、ジーニアス）。 == Can you ? == 英語では、相手に能力を直接聞くのは、失礼に当たると見なされている場合もある。 たとえば、 Can you speak Japanese? は、背景として、「あなたは日本語を話せないといけない」と思われることもある（インスパイア、ジーニアス）。このため、canを使わずに Do you speak Japanese? と聞くのが良いとされている（ジーニアス）。 一方、話し手が自分の語学の能力を「私は～できます」と言う場合は、なるべく be able to よりも canを使うほうが謙遜気味で礼儀正しいとされており、つまり I can のほうが良いとされている（ジーニアス）。I のあとに be able to を使うと、英米では能力自慢のように聞こえるらしい（ジーニアス）。 can youが無礼なのに I can が礼儀正しいのは意味不明だが、しかし覇権国家の英米人がそう使い分けているので、英語学ではそう合わせるしかない。うらやましい。所詮、語学は暗記科目であり、「理屈と膏薬はどこにでもつく」（日本のことわざ）である。 また、派生的にか、可能性のcanは疑問文では、強めの疑いや、おどろきや当惑などの意味をもつこともよくある（青チャート、インスパイア）。参考書によくある典型的な例文だが Can the rumor be true? 「そのウワサは本当だろうか？」 という疑問文では、そのような、強めの疑いや、おどろきなどの意味がある。・ さて、can は、今後も通用する能力や可能性について言うので、単に一回だけのことに「昨日は～できた」みたいに言う場合には can や could を使わない（ジーニアス、青チャート）。 1回だけ「～できた」場合には、 be able to や 「managed to不定詞」 や succeed in ～ing などを使う（青チャート、インスパイア）。 また、とくに能力などを強調するのでなければ、単に過去形だけを使って1回だけできたことを表現してもいい（ジーニアス）。 なお、否定文や疑問文の場合は could を使っても良く、つまり couldn't や wasn't（または weren't） able to でもいい（インスパイア）。 ただし、こういう細かい使い分けよりも、入試に出るのは、構文 cannot help ～ing 「～せざるを得ない」 cannot help but ＋動詞の原型 「～せざるを得ない」 cannot but ＋動詞の原型 などだろう（インスパイア、桐原ファクトブック）。 90年代、こういう二重否定的な構文が（中学範囲ではなく）高校範囲だった過去がある。 cannot ～ too ○○ 「いくら～しすぎても○○しすぎることはない」 という反語的な表現も、90年代の典型的な高校英文法の範囲であった。 そのほか、「ときに　～することがある」と好ましくない事を言う場合に can を使うことがある。ジーニアスいわく「風邪は時に重い病気につながることがある」とか、青チャートいわく「そういう事故はときどき起こりうるものだ」で can を使っている。 だが、これとは逆に思える用法もインスパイアにあり、「can はもともと備わっている能力を表す」として「be able to は一時的な能力を表す」などという用法もある。 ※ このように、助動詞まわりは、あまり規則的ではなく、またやや口語的であり、あまり日本の大学入試対策としては深入りする必要が無いだろう。上述したが cannot help ～ ing のような構文を覚えることを優先すべきである。 == 助動詞 need == 本動詞 need とは別に、助動詞 need というのがあり、 「need ＋動詞の原型」の形で使う。 助動詞 need は主にイギリス英語である。 参考書では平叙文に助動詞 need が使われることもあるが（ジーニアス）、しかし実際の英米では疑問文と否定文でのみ助動詞 need が使われるのが一般的である（青チャート、桐原ファクト）。 このような制限が助動詞 need にあるため、実のところ、あまり信用頻度は高くない、・・・というのが桐原ファクトの見解。 助動詞 need の否定形は need not または needn't であり（青チャ－ト）、つまり「 need not ＋動詞の原型」のような形になる。 また、助動詞 need に過去形は無い（青チャ、インスパ）。また、主語が三人称単数でも、助動詞 need には sはつかず、needのまま（青チャ）。 もし、過去の必要性について言いたい場合、単に、本動詞 「need to不定詞」を使えばいい（ジーニアス、青チャ、インスパイア）。 なお、本動詞 need の否定文や疑問文は、単に中学英文法と同様に I didn't need to 不定詞 や Did you need to 不定詞 ? を使えばいいだけである。 なお、完了形との組み合わせ「 need not have ＋過去分詞」だと、「～する必要はなかったのに」という意味になる（ジーニアス）。 == dare == 助動詞としては、2つの慣用文がある。 How dare say ～？　「よくも～できたものだね」 という苛立ち（いらだち）をあらわす。 I dare say ～. 「たぶん～だろう」「おそらく～だろう」 sayのあとに接続詞 that は続かない（インスパイア）。 I daresay ～ という一語でdareとsayを縮めた言い回しもある（インスパイア、ブレイクスルー）。 dare の用法は、あまり論理的ではない。ほか、助動詞 dareに過去形 dared もあるとされているが、現代ではマレ（青チャート）。 そのほか、 Bod dare not propose to her. 「ボブは彼女にプロポーズする勇気がない」 のように、否定文や疑問文で dare が使われることがある。 だが、この場合の dare は「勇気のある」の意味なので、助動詞を使わずとも courage や brave などをつかった言い表すこともできて、むしろ英米では口語には courage などの言い回しのほうが多いのが実態とのこと（エバーグリーン）。 さて、助動詞以外にも、本動詞としての dare の用法があり、上記２つの「How dare」「I dare say（または daresay）」慣用表現以外の場合では、本動詞としてdareをつかうことのほうが一般的であり（ジーニアス）、 He dares（または dared） to ～ 「彼はずうずうしくも～する（した）」 のように使うこともある（青チャ）。 fkdd6a35vm33x4onm6rt0zeld1uqnmt 205938 205937 2022-07-28T09:48:24Z すじにくシチュー 12058 /* 助動詞 need */ wikitext text/x-wiki == must == === 勧誘 must === must には、強い勧誘を意味する用法もある（インスパイア、桐原ファクトブック、ジーニアス）。 You must ～. 「ぜひ～してください」「ぜひ～したほうがいい」 のような意味。 青チャートには書いていない。（あまり重要視してないのだろう。） 欧米人は、この手の、外国人には分かりづらい、やや飛躍気味の表現をすることもよくある。 :※ 飛躍気味とは、たとえば最近の俗語の例では、英米人の近年の若者などの用法で、すばらしい絵や文芸を見たときに、「その絵を消してくれ」なんていう表現も最近の英語では良く使われるという。どうやら「素晴らしすぎて、魅了されて、頭がおかしくなってしまいそうだ」→「だから消してくれ」という意味らしいのだが、しかし事情が知らない外国人が聞くと、単にその絵や文芸に不満があるかと誤解されかねない。しかし、英語は世界の覇権言語なので、外国人からの誤解を気にする必要も無い。日本人からすれば、まったく、英米人はうらやましい限りである。 この 勧誘の must を紹介しているインスパイア、ジーニアスも、コラム的に紹介しているだけである。（桐原ファクトのみ、本文で紹介。） :※ 昔から教育評論でよく言われる、英語教育の隠れた目的のひとつとして、誤解の恐れの少ない論理的な文章の書き方の教育を教える、という目的がある。文科省や国立大学などは、中立性などの理由で、「論理的な日本語の書き方はこうあるべきし」とは宣言できないので、仕方なく英文法など外国語を使って論理的な文章の書き方を教えようとしている、などとは昔はよく評論されたものである（もっとも、最近の英語教育では会話重視などで、そういう論理性の教育目的は雲散霧消してしまったが）。そういう論理的な文章の書き方の教育としては、勧誘 must やら上記例の「消してくれ」のような飛躍気味の用法は、嫌われるだろうから、大学入試などに勧誘の must などが出る可能性は低いかもしれない。 == 確信「ちがいない」 must の否定 == 「～にちがいない」という強い確認の意味での must の否定は、 cannot 「～はずがない」である（ジーニアス、インスパイア、青チャート）。 なぜそうかといわれても、そうだと決まってる。英米人がそういう使い方をしているので、合わせるしかない。 :※ これまた、あまり論理的でないので、おそらく入試では問われづらいだろう。たとえば桐原ファクトでは、must の項目では、確信の否定 cannot を無視しており、非紹介である。なお、桐原でも can の側で cannot「～はずがない」を説明しており、可能性 can の否定として cannot「～はずがない」 という用法を説明するというのが桐原ファクトの理論構成である。 cannot や can't と言った場合、単に「～できない」という可能性を否定するだけの用法もあるが（インスパイア　can側）、それとは別に「～のはずがない」という強めの感情的色彩をおびた「否定の確信」な意味の用法の場合もある（桐原ファクト、ジーニアス）。 == Can you ? == 英語では、相手に能力を直接聞くのは、失礼に当たると見なされている場合もある。 たとえば、 Can you speak Japanese? は、背景として、「あなたは日本語を話せないといけない」と思われることもある（インスパイア、ジーニアス）。このため、canを使わずに Do you speak Japanese? と聞くのが良いとされている（ジーニアス）。 一方、話し手が自分の語学の能力を「私は～できます」と言う場合は、なるべく be able to よりも canを使うほうが謙遜気味で礼儀正しいとされており、つまり I can のほうが良いとされている（ジーニアス）。I のあとに be able to を使うと、英米では能力自慢のように聞こえるらしい（ジーニアス）。 can youが無礼なのに I can が礼儀正しいのは意味不明だが、しかし覇権国家の英米人がそう使い分けているので、英語学ではそう合わせるしかない。うらやましい。所詮、語学は暗記科目であり、「理屈と膏薬はどこにでもつく」（日本のことわざ）である。 また、派生的にか、可能性のcanは疑問文では、強めの疑いや、おどろきや当惑などの意味をもつこともよくある（青チャート、インスパイア）。参考書によくある典型的な例文だが Can the rumor be true? 「そのウワサは本当だろうか？」 という疑問文では、そのような、強めの疑いや、おどろきなどの意味がある。・ さて、can は、今後も通用する能力や可能性について言うので、単に一回だけのことに「昨日は～できた」みたいに言う場合には can や could を使わない（ジーニアス、青チャート）。 1回だけ「～できた」場合には、 be able to や 「managed to不定詞」 や succeed in ～ing などを使う（青チャート、インスパイア）。 また、とくに能力などを強調するのでなければ、単に過去形だけを使って1回だけできたことを表現してもいい（ジーニアス）。 なお、否定文や疑問文の場合は could を使っても良く、つまり couldn't や wasn't（または weren't） able to でもいい（インスパイア）。 ただし、こういう細かい使い分けよりも、入試に出るのは、構文 cannot help ～ing 「～せざるを得ない」 cannot help but ＋動詞の原型 「～せざるを得ない」 cannot but ＋動詞の原型 などだろう（インスパイア、桐原ファクトブック）。 90年代、こういう二重否定的な構文が（中学範囲ではなく）高校範囲だった過去がある。 cannot ～ too ○○ 「いくら～しすぎても○○しすぎることはない」 という反語的な表現も、90年代の典型的な高校英文法の範囲であった。 そのほか、「ときに　～することがある」と好ましくない事を言う場合に can を使うことがある。ジーニアスいわく「風邪は時に重い病気につながることがある」とか、青チャートいわく「そういう事故はときどき起こりうるものだ」で can を使っている。 だが、これとは逆に思える用法もインスパイアにあり、「can はもともと備わっている能力を表す」として「be able to は一時的な能力を表す」などという用法もある。 ※ このように、助動詞まわりは、あまり規則的ではなく、またやや口語的であり、あまり日本の大学入試対策としては深入りする必要が無いだろう。上述したが cannot help ～ ing のような構文を覚えることを優先すべきである。 == 助動詞 need == 本動詞 need とは別に、助動詞 need というのがあり、 「need ＋動詞の原型」の形で使う。 助動詞 need は主にイギリス英語である。 参考書では平叙文に助動詞 need が使われることもあるが（ジーニアス）、しかし実際の英米では疑問文と否定文でのみ助動詞 need が使われるのが一般的である（青チャート、桐原ファクト）。 このような制限が助動詞 need にあるため、実のところ、あまり信用頻度は高くない、・・・というのが桐原ファクトの見解。 助動詞 need の否定形は need not または needn't であり（青チャ－ト）、つまり「 need not ＋動詞の原型」のような形になる。 また、助動詞 need に過去形は無い（青チャ、インスパ）。また、主語が三人称単数でも、助動詞 need には sはつかず、needのまま（青チャ）。 もし、過去の必要性について言いたい場合、単に、本動詞 「need to不定詞」を使えばいい（ジーニアス、青チャ、インスパイア）。 なお、本動詞 need の否定文や疑問文は、単に中学英文法と同様に I didn't need to 不定詞 や Did you need to 不定詞 ? を使えばいいだけである。 なお、完了形との組み合わせ「 need not have ＋過去分詞」だと、「～する必要はなかったのに」（＋「しかし実際は～してしまった」）という意味になる（ジーニアス、インスパイア）。 ※ インスパイアに「実際は～してしまった」の説明あり。 == dare == 助動詞としては、2つの慣用文がある。 How dare say ～？　「よくも～できたものだね」 という苛立ち（いらだち）をあらわす。 I dare say ～. 「たぶん～だろう」「おそらく～だろう」 sayのあとに接続詞 that は続かない（インスパイア）。 I daresay ～ という一語でdareとsayを縮めた言い回しもある（インスパイア、ブレイクスルー）。 dare の用法は、あまり論理的ではない。ほか、助動詞 dareに過去形 dared もあるとされているが、現代ではマレ（青チャート）。 そのほか、 Bod dare not propose to her. 「ボブは彼女にプロポーズする勇気がない」 のように、否定文や疑問文で dare が使われることがある。 だが、この場合の dare は「勇気のある」の意味なので、助動詞を使わずとも courage や brave などをつかった言い表すこともできて、むしろ英米では口語には courage などの言い回しのほうが多いのが実態とのこと（エバーグリーン）。 さて、助動詞以外にも、本動詞としての dare の用法があり、上記２つの「How dare」「I dare say（または daresay）」慣用表現以外の場合では、本動詞としてdareをつかうことのほうが一般的であり（ジーニアス）、 He dares（または dared） to ～ 「彼はずうずうしくも～する（した）」 のように使うこともある（青チャ）。 9iwa0xg2wlfvn1lt0vix11epl65hy82 205939 205938 2022-07-28T10:08:52Z すじにくシチュー 12058 wikitext text/x-wiki == must == === 勧誘 must === must には、強い勧誘を意味する用法もある（インスパイア、桐原ファクトブック、ジーニアス）。 You must ～. 「ぜひ～してください」「ぜひ～したほうがいい」 のような意味。 青チャートには書いていない。（あまり重要視してないのだろう。） 欧米人は、この手の、外国人には分かりづらい、やや飛躍気味の表現をすることもよくある。 :※ 飛躍気味とは、たとえば最近の俗語の例では、英米人の近年の若者などの用法で、すばらしい絵や文芸を見たときに、「その絵を消してくれ」なんていう表現も最近の英語では良く使われるという。どうやら「素晴らしすぎて、魅了されて、頭がおかしくなってしまいそうだ」→「だから消してくれ」という意味らしいのだが、しかし事情が知らない外国人が聞くと、単にその絵や文芸に不満があるかと誤解されかねない。しかし、英語は世界の覇権言語なので、外国人からの誤解を気にする必要も無い。日本人からすれば、まったく、英米人はうらやましい限りである。 この 勧誘の must を紹介しているインスパイア、ジーニアスも、コラム的に紹介しているだけである。（桐原ファクトのみ、本文で紹介。） :※ 昔から教育評論でよく言われる、英語教育の隠れた目的のひとつとして、誤解の恐れの少ない論理的な文章の書き方の教育を教える、という目的がある。文科省や国立大学などは、中立性などの理由で、「論理的な日本語の書き方はこうあるべきし」とは宣言できないので、仕方なく英文法など外国語を使って論理的な文章の書き方を教えようとしている、などとは昔はよく評論されたものである（もっとも、最近の英語教育では会話重視などで、そういう論理性の教育目的は雲散霧消してしまったが）。そういう論理的な文章の書き方の教育としては、勧誘 must やら上記例の「消してくれ」のような飛躍気味の用法は、嫌われるだろうから、大学入試などに勧誘の must などが出る可能性は低いかもしれない。 == 確信「ちがいない」 must の否定 == 「～にちがいない」という強い確認の意味での must の否定は、 cannot 「～はずがない」である（ジーニアス、インスパイア、青チャート）。 なぜそうかといわれても、そうだと決まってる。英米人がそういう使い方をしているので、合わせるしかない。 :※ これまた、あまり論理的でないので、おそらく入試では問われづらいだろう。たとえば桐原ファクトでは、must の項目では、確信の否定 cannot を無視しており、非紹介である。なお、桐原でも can の側で cannot「～はずがない」を説明しており、可能性 can の否定として cannot「～はずがない」 という用法を説明するというのが桐原ファクトの理論構成である。 cannot や can't と言った場合、単に「～できない」という可能性を否定するだけの用法もあるが（インスパイア　can側）、それとは別に「～のはずがない」という強めの感情的色彩をおびた「否定の確信」な意味の用法の場合もある（桐原ファクト、ジーニアス）。 == Can you ? == 英語では、相手に能力を直接聞くのは、失礼に当たると見なされている場合もある。 たとえば、 Can you speak Japanese? は、背景として、「あなたは日本語を話せないといけない」と思われることもある（インスパイア、ジーニアス）。このため、canを使わずに Do you speak Japanese? と聞くのが良いとされている（ジーニアス）。 一方、話し手が自分の語学の能力を「私は～できます」と言う場合は、なるべく be able to よりも canを使うほうが謙遜気味で礼儀正しいとされており、つまり I can のほうが良いとされている（ジーニアス）。I のあとに be able to を使うと、英米では能力自慢のように聞こえるらしい（ジーニアス）。 can youが無礼なのに I can が礼儀正しいのは意味不明だが、しかし覇権国家の英米人がそう使い分けているので、英語学ではそう合わせるしかない。うらやましい。所詮、語学は暗記科目であり、「理屈と膏薬はどこにでもつく」（日本のことわざ）である。 また、派生的にか、可能性のcanは疑問文では、強めの疑いや、おどろきや当惑などの意味をもつこともよくある（青チャート、インスパイア）。参考書によくある典型的な例文だが Can the rumor be true? 「そのウワサは本当だろうか？」 という疑問文では、そのような、強めの疑いや、おどろきなどの意味がある。・ さて、can は、今後も通用する能力や可能性について言うので、単に一回だけのことに「昨日は～できた」みたいに言う場合には can や could を使わない（ジーニアス、青チャート）。 1回だけ「～できた」場合には、 be able to や 「managed to不定詞」 や succeed in ～ing などを使う（青チャート、インスパイア）。 また、とくに能力などを強調するのでなければ、単に過去形だけを使って1回だけできたことを表現してもいい（ジーニアス）。 なお、否定文や疑問文の場合は could を使っても良く、つまり couldn't や wasn't（または weren't） able to でもいい（インスパイア）。 ただし、こういう細かい使い分けよりも、入試に出るのは、構文 cannot help ～ing 「～せざるを得ない」 cannot help but ＋動詞の原型 「～せざるを得ない」 cannot but ＋動詞の原型 などだろう（インスパイア、桐原ファクトブック）。 90年代、こういう二重否定的な構文が（中学範囲ではなく）高校範囲だった過去がある。 cannot ～ too ○○ 「いくら～しすぎても○○しすぎることはない」 という反語的な表現も、90年代の典型的な高校英文法の範囲であった。 そのほか、「ときに　～することがある」と好ましくない事を言う場合に can を使うことがある。ジーニアスいわく「風邪は時に重い病気につながることがある」とか、青チャートいわく「そういう事故はときどき起こりうるものだ」で can を使っている。 だが、これとは逆に思える用法もインスパイアにあり、「can はもともと備わっている能力を表す」として「be able to は一時的な能力を表す」などという用法もある。 ※ このように、助動詞まわりは、あまり規則的ではなく、またやや口語的であり、あまり日本の大学入試対策としては深入りする必要が無いだろう。上述したが cannot help ～ ing のような構文を覚えることを優先すべきである。 == 助動詞 need == 本動詞 need とは別に、助動詞 need というのがあり、 「need ＋動詞の原型」の形で使う。 助動詞 need は主にイギリス英語である。 参考書では平叙文に助動詞 need が使われることもあるが（ジーニアス）、しかし実際の英米では疑問文と否定文でのみ助動詞 need が使われるのが一般的である（青チャート、桐原ファクト）。 このような制限が助動詞 need にあるため、実のところ、あまり信用頻度は高くない、・・・というのが桐原ファクトの見解。 助動詞 need の否定形は need not または needn't であり（青チャ－ト）、つまり「 need not ＋動詞の原型」のような形になる。 また、助動詞 need に過去形は無い（青チャ、インスパ）。また、主語が三人称単数でも、助動詞 need には sはつかず、needのまま（青チャ）。 もし、過去の必要性について言いたい場合、単に、本動詞 「need to不定詞」を使えばいい（ジーニアス、青チャ、インスパイア）。 なお、本動詞 need の否定文や疑問文は、単に中学英文法と同様に I didn't need to 不定詞 や Did you need to 不定詞 ? を使えばいいだけである。 なお、完了形との組み合わせ「 need not have ＋過去分詞」だと、「～する必要はなかったのに」（＋「しかし実際は～してしまった」）という意味になる（ジーニアス、インスパイア）。 ※ インスパイアに「実際は～してしまった」の説明あり。 == dare == 助動詞としては、2つの慣用文がある。 How dare say ～？　「よくも～できたものだね」 という苛立ち（いらだち）をあらわす。 I dare say ～. 「たぶん～だろう」「おそらく～だろう」 sayのあとに接続詞 that は続かない（インスパイア）。 I daresay ～ という一語でdareとsayを縮めた言い回しもある（インスパイア、ブレイクスルー）。 dare の用法は、あまり論理的ではない。ほか、助動詞 dareに過去形 dared もあるとされているが、現代ではマレ（青チャート）。 そのほか、 Bod dare not propose to her. 「ボブは彼女にプロポーズする勇気がない」 のように、否定文や疑問文で dare が使われることがある。 だが、この場合の dare は「勇気のある」の意味なので、助動詞を使わずとも courage や brave などをつかった言い表すこともできて、むしろ英米では口語には courage などの言い回しのほうが多いのが実態とのこと（エバーグリーン）。 さて、助動詞以外にも、本動詞としての dare の用法があり、上記２つの「How dare」「I dare say（または daresay）」慣用表現以外の場合では、本動詞としてdareをつかうことのほうが一般的であり（ジーニアス）、 He dares（または dared） to ～ 「彼はずうずうしくも～する（した）」 のように使うこともある（青チャ）。 == ought to == ought to は、助動詞 should と同じような意味として紹介されることもある。だが、実際には should よりも、やや意味が強い。 ought to には、「～すべきである」という義務・当然の意味や、「～するはずだ」「～にちがいない」という強い推定・見込みの意味（インスパイア、青チャ）がある。 義務の強さは、 must ＞ ought to ＞ should である（ジーニアス）。 ought は助動詞であるが、to不定詞とともに使われる。 なお、ought to の否定形は ought not to ～ である（エバー、青）。 oughtn't to ～ という短縮形の否定もある（青）。 gimo疑問文は、たとえば「私は～すべきでしょうか？」なら Ought I to 不定詞 ～? の語順になる（青、ファクト）。 つまり、 Ought 主語 to 不定詞 ～? の語順。 n1qblicu6uu1ahaauahji9ww6gldd7h 205940 205939 2022-07-28T10:21:23Z すじにくシチュー 12058 had better wikitext text/x-wiki == must == === 勧誘 must === must には、強い勧誘を意味する用法もある（インスパイア、桐原ファクトブック、ジーニアス）。 You must ～. 「ぜひ～してください」「ぜひ～したほうがいい」 のような意味。 青チャートには書いていない。（あまり重要視してないのだろう。） 欧米人は、この手の、外国人には分かりづらい、やや飛躍気味の表現をすることもよくある。 :※ 飛躍気味とは、たとえば最近の俗語の例では、英米人の近年の若者などの用法で、すばらしい絵や文芸を見たときに、「その絵を消してくれ」なんていう表現も最近の英語では良く使われるという。どうやら「素晴らしすぎて、魅了されて、頭がおかしくなってしまいそうだ」→「だから消してくれ」という意味らしいのだが、しかし事情が知らない外国人が聞くと、単にその絵や文芸に不満があるかと誤解されかねない。しかし、英語は世界の覇権言語なので、外国人からの誤解を気にする必要も無い。日本人からすれば、まったく、英米人はうらやましい限りである。 この 勧誘の must を紹介しているインスパイア、ジーニアスも、コラム的に紹介しているだけである。（桐原ファクトのみ、本文で紹介。） :※ 昔から教育評論でよく言われる、英語教育の隠れた目的のひとつとして、誤解の恐れの少ない論理的な文章の書き方の教育を教える、という目的がある。文科省や国立大学などは、中立性などの理由で、「論理的な日本語の書き方はこうあるべきし」とは宣言できないので、仕方なく英文法など外国語を使って論理的な文章の書き方を教えようとしている、などとは昔はよく評論されたものである（もっとも、最近の英語教育では会話重視などで、そういう論理性の教育目的は雲散霧消してしまったが）。そういう論理的な文章の書き方の教育としては、勧誘 must やら上記例の「消してくれ」のような飛躍気味の用法は、嫌われるだろうから、大学入試などに勧誘の must などが出る可能性は低いかもしれない。 == 確信「ちがいない」 must の否定 == 「～にちがいない」という強い確認の意味での must の否定は、 cannot 「～はずがない」である（ジーニアス、インスパイア、青チャート）。 なぜそうかといわれても、そうだと決まってる。英米人がそういう使い方をしているので、合わせるしかない。 :※ これまた、あまり論理的でないので、おそらく入試では問われづらいだろう。たとえば桐原ファクトでは、must の項目では、確信の否定 cannot を無視しており、非紹介である。なお、桐原でも can の側で cannot「～はずがない」を説明しており、可能性 can の否定として cannot「～はずがない」 という用法を説明するというのが桐原ファクトの理論構成である。 cannot や can't と言った場合、単に「～できない」という可能性を否定するだけの用法もあるが（インスパイア　can側）、それとは別に「～のはずがない」という強めの感情的色彩をおびた「否定の確信」な意味の用法の場合もある（桐原ファクト、ジーニアス）。 == Can you ? == 英語では、相手に能力を直接聞くのは、失礼に当たると見なされている場合もある。 たとえば、 Can you speak Japanese? は、背景として、「あなたは日本語を話せないといけない」と思われることもある（インスパイア、ジーニアス）。このため、canを使わずに Do you speak Japanese? と聞くのが良いとされている（ジーニアス）。 一方、話し手が自分の語学の能力を「私は～できます」と言う場合は、なるべく be able to よりも canを使うほうが謙遜気味で礼儀正しいとされており、つまり I can のほうが良いとされている（ジーニアス）。I のあとに be able to を使うと、英米では能力自慢のように聞こえるらしい（ジーニアス）。 can youが無礼なのに I can が礼儀正しいのは意味不明だが、しかし覇権国家の英米人がそう使い分けているので、英語学ではそう合わせるしかない。うらやましい。所詮、語学は暗記科目であり、「理屈と膏薬はどこにでもつく」（日本のことわざ）である。 また、派生的にか、可能性のcanは疑問文では、強めの疑いや、おどろきや当惑などの意味をもつこともよくある（青チャート、インスパイア）。参考書によくある典型的な例文だが Can the rumor be true? 「そのウワサは本当だろうか？」 という疑問文では、そのような、強めの疑いや、おどろきなどの意味がある。・ さて、can は、今後も通用する能力や可能性について言うので、単に一回だけのことに「昨日は～できた」みたいに言う場合には can や could を使わない（ジーニアス、青チャート）。 1回だけ「～できた」場合には、 be able to や 「managed to不定詞」 や succeed in ～ing などを使う（青チャート、インスパイア）。 また、とくに能力などを強調するのでなければ、単に過去形だけを使って1回だけできたことを表現してもいい（ジーニアス）。 なお、否定文や疑問文の場合は could を使っても良く、つまり couldn't や wasn't（または weren't） able to でもいい（インスパイア）。 ただし、こういう細かい使い分けよりも、入試に出るのは、構文 cannot help ～ing 「～せざるを得ない」 cannot help but ＋動詞の原型 「～せざるを得ない」 cannot but ＋動詞の原型 などだろう（インスパイア、桐原ファクトブック）。 90年代、こういう二重否定的な構文が（中学範囲ではなく）高校範囲だった過去がある。 cannot ～ too ○○ 「いくら～しすぎても○○しすぎることはない」 という反語的な表現も、90年代の典型的な高校英文法の範囲であった。 そのほか、「ときに　～することがある」と好ましくない事を言う場合に can を使うことがある。ジーニアスいわく「風邪は時に重い病気につながることがある」とか、青チャートいわく「そういう事故はときどき起こりうるものだ」で can を使っている。 だが、これとは逆に思える用法もインスパイアにあり、「can はもともと備わっている能力を表す」として「be able to は一時的な能力を表す」などという用法もある。 ※ このように、助動詞まわりは、あまり規則的ではなく、またやや口語的であり、あまり日本の大学入試対策としては深入りする必要が無いだろう。上述したが cannot help ～ ing のような構文を覚えることを優先すべきである。 == 助動詞 need == 本動詞 need とは別に、助動詞 need というのがあり、 「need ＋動詞の原型」の形で使う。 助動詞 need は主にイギリス英語である。 参考書では平叙文に助動詞 need が使われることもあるが（ジーニアス）、しかし実際の英米では疑問文と否定文でのみ助動詞 need が使われるのが一般的である（青チャート、桐原ファクト）。 このような制限が助動詞 need にあるため、実のところ、あまり信用頻度は高くない、・・・というのが桐原ファクトの見解。 助動詞 need の否定形は need not または needn't であり（青チャ－ト）、つまり「 need not ＋動詞の原型」のような形になる。 また、助動詞 need に過去形は無い（青チャ、インスパ）。また、主語が三人称単数でも、助動詞 need には sはつかず、needのまま（青チャ）。 もし、過去の必要性について言いたい場合、単に、本動詞 「need to不定詞」を使えばいい（ジーニアス、青チャ、インスパイア）。 なお、本動詞 need の否定文や疑問文は、単に中学英文法と同様に I didn't need to 不定詞 や Did you need to 不定詞 ? を使えばいいだけである。 なお、完了形との組み合わせ「 need not have ＋過去分詞」だと、「～する必要はなかったのに」（＋「しかし実際は～してしまった」）という意味になる（ジーニアス、インスパイア）。 ※ インスパイアに「実際は～してしまった」の説明あり。 == dare == 助動詞としては、2つの慣用文がある。 How dare say ～？　「よくも～できたものだね」 という苛立ち（いらだち）をあらわす。 I dare say ～. 「たぶん～だろう」「おそらく～だろう」 sayのあとに接続詞 that は続かない（インスパイア）。 I daresay ～ という一語でdareとsayを縮めた言い回しもある（インスパイア、ブレイクスルー）。 dare の用法は、あまり論理的ではない。ほか、助動詞 dareに過去形 dared もあるとされているが、現代ではマレ（青チャート）。 そのほか、 Bod dare not propose to her. 「ボブは彼女にプロポーズする勇気がない」 のように、否定文や疑問文で dare が使われることがある。 だが、この場合の dare は「勇気のある」の意味なので、助動詞を使わずとも courage や brave などをつかった言い表すこともできて、むしろ英米では口語には courage などの言い回しのほうが多いのが実態とのこと（エバーグリーン）。 さて、助動詞以外にも、本動詞としての dare の用法があり、上記２つの「How dare」「I dare say（または daresay）」慣用表現以外の場合では、本動詞としてdareをつかうことのほうが一般的であり（ジーニアス）、 He dares（または dared） to ～ 「彼はずうずうしくも～する（した）」 のように使うこともある（青チャ）。 == ought to == ought to は、助動詞 should と同じような意味として紹介されることもある。だが、実際には should よりも、やや意味が強い。 ought to には、「～すべきである」という義務・当然の意味や、「～するはずだ」「～にちがいない」という強い推定・見込みの意味（インスパイア、青チャ）がある。 義務の強さは、 must ＞ ought to ＞ should である（ジーニアス）。 ought は助動詞であるが、to不定詞とともに使われる。 なお、ought to の否定形は ought not to ～ である（エバー、青）。 oughtn't to ～ という短縮形の否定もある（青）。 gimo疑問文は、たとえば「私は～すべきでしょうか？」なら Ought I to 不定詞 ～? の語順になる（青、ファクト）。 つまり、 Ought 主語 to 不定詞 ～? の語順。 == had better == had better 「～したほうがいい」は、字面だけなら「推奨」の意味だが、文脈によっては「命令」や「脅し」の意味に受け取られる場合がある。 had better には「そうしないと（or）、困った事になるぞ」という含みがあると感じられる場合があるから、である（桐原ファクト、）。 とくに、主語が you の場合、命令などの意味に受け取られやすいので、注意が必要（エバー）。 このため、 I think you had better ～　のように「I think 」や maybe などをつけて、意味をやわらげる場合もよくある。 had better の否定は 「had better not 動詞の原型」である（エバ、ジーニ）。 :※ 完了形と混同してか、had better なのに had の後ろに not を置くミスが学生に多い（エバ）。 「It would be better for you to 不定詞」でも、意味をやわらげられる（青チャート、インスパ）ので、目上の人にはこの言い回しが良いとされる（青チャ）。 d148k2eq37qgjz0radfgoqwt4vxjyzd 205941 205940 2022-07-28T10:25:41Z すじにくシチュー 12058 /* had better */ wikitext text/x-wiki == must == === 勧誘 must === must には、強い勧誘を意味する用法もある（インスパイア、桐原ファクトブック、ジーニアス）。 You must ～. 「ぜひ～してください」「ぜひ～したほうがいい」 のような意味。 青チャートには書いていない。（あまり重要視してないのだろう。） 欧米人は、この手の、外国人には分かりづらい、やや飛躍気味の表現をすることもよくある。 :※ 飛躍気味とは、たとえば最近の俗語の例では、英米人の近年の若者などの用法で、すばらしい絵や文芸を見たときに、「その絵を消してくれ」なんていう表現も最近の英語では良く使われるという。どうやら「素晴らしすぎて、魅了されて、頭がおかしくなってしまいそうだ」→「だから消してくれ」という意味らしいのだが、しかし事情が知らない外国人が聞くと、単にその絵や文芸に不満があるかと誤解されかねない。しかし、英語は世界の覇権言語なので、外国人からの誤解を気にする必要も無い。日本人からすれば、まったく、英米人はうらやましい限りである。 この 勧誘の must を紹介しているインスパイア、ジーニアスも、コラム的に紹介しているだけである。（桐原ファクトのみ、本文で紹介。） :※ 昔から教育評論でよく言われる、英語教育の隠れた目的のひとつとして、誤解の恐れの少ない論理的な文章の書き方の教育を教える、という目的がある。文科省や国立大学などは、中立性などの理由で、「論理的な日本語の書き方はこうあるべきし」とは宣言できないので、仕方なく英文法など外国語を使って論理的な文章の書き方を教えようとしている、などとは昔はよく評論されたものである（もっとも、最近の英語教育では会話重視などで、そういう論理性の教育目的は雲散霧消してしまったが）。そういう論理的な文章の書き方の教育としては、勧誘 must やら上記例の「消してくれ」のような飛躍気味の用法は、嫌われるだろうから、大学入試などに勧誘の must などが出る可能性は低いかもしれない。 == 確信「ちがいない」 must の否定 == 「～にちがいない」という強い確認の意味での must の否定は、 cannot 「～はずがない」である（ジーニアス、インスパイア、青チャート）。 なぜそうかといわれても、そうだと決まってる。英米人がそういう使い方をしているので、合わせるしかない。 :※ これまた、あまり論理的でないので、おそらく入試では問われづらいだろう。たとえば桐原ファクトでは、must の項目では、確信の否定 cannot を無視しており、非紹介である。なお、桐原でも can の側で cannot「～はずがない」を説明しており、可能性 can の否定として cannot「～はずがない」 という用法を説明するというのが桐原ファクトの理論構成である。 cannot や can't と言った場合、単に「～できない」という可能性を否定するだけの用法もあるが（インスパイア　can側）、それとは別に「～のはずがない」という強めの感情的色彩をおびた「否定の確信」な意味の用法の場合もある（桐原ファクト、ジーニアス）。 == Can you ? == 英語では、相手に能力を直接聞くのは、失礼に当たると見なされている場合もある。 たとえば、 Can you speak Japanese? は、背景として、「あなたは日本語を話せないといけない」と思われることもある（インスパイア、ジーニアス）。このため、canを使わずに Do you speak Japanese? と聞くのが良いとされている（ジーニアス）。 一方、話し手が自分の語学の能力を「私は～できます」と言う場合は、なるべく be able to よりも canを使うほうが謙遜気味で礼儀正しいとされており、つまり I can のほうが良いとされている（ジーニアス）。I のあとに be able to を使うと、英米では能力自慢のように聞こえるらしい（ジーニアス）。 can youが無礼なのに I can が礼儀正しいのは意味不明だが、しかし覇権国家の英米人がそう使い分けているので、英語学ではそう合わせるしかない。うらやましい。所詮、語学は暗記科目であり、「理屈と膏薬はどこにでもつく」（日本のことわざ）である。 また、派生的にか、可能性のcanは疑問文では、強めの疑いや、おどろきや当惑などの意味をもつこともよくある（青チャート、インスパイア）。参考書によくある典型的な例文だが Can the rumor be true? 「そのウワサは本当だろうか？」 という疑問文では、そのような、強めの疑いや、おどろきなどの意味がある。・ さて、can は、今後も通用する能力や可能性について言うので、単に一回だけのことに「昨日は～できた」みたいに言う場合には can や could を使わない（ジーニアス、青チャート）。 1回だけ「～できた」場合には、 be able to や 「managed to不定詞」 や succeed in ～ing などを使う（青チャート、インスパイア）。 また、とくに能力などを強調するのでなければ、単に過去形だけを使って1回だけできたことを表現してもいい（ジーニアス）。 なお、否定文や疑問文の場合は could を使っても良く、つまり couldn't や wasn't（または weren't） able to でもいい（インスパイア）。 ただし、こういう細かい使い分けよりも、入試に出るのは、構文 cannot help ～ing 「～せざるを得ない」 cannot help but ＋動詞の原型 「～せざるを得ない」 cannot but ＋動詞の原型 などだろう（インスパイア、桐原ファクトブック）。 90年代、こういう二重否定的な構文が（中学範囲ではなく）高校範囲だった過去がある。 cannot ～ too ○○ 「いくら～しすぎても○○しすぎることはない」 という反語的な表現も、90年代の典型的な高校英文法の範囲であった。 そのほか、「ときに　～することがある」と好ましくない事を言う場合に can を使うことがある。ジーニアスいわく「風邪は時に重い病気につながることがある」とか、青チャートいわく「そういう事故はときどき起こりうるものだ」で can を使っている。 だが、これとは逆に思える用法もインスパイアにあり、「can はもともと備わっている能力を表す」として「be able to は一時的な能力を表す」などという用法もある。 ※ このように、助動詞まわりは、あまり規則的ではなく、またやや口語的であり、あまり日本の大学入試対策としては深入りする必要が無いだろう。上述したが cannot help ～ ing のような構文を覚えることを優先すべきである。 == 助動詞 need == 本動詞 need とは別に、助動詞 need というのがあり、 「need ＋動詞の原型」の形で使う。 助動詞 need は主にイギリス英語である。 参考書では平叙文に助動詞 need が使われることもあるが（ジーニアス）、しかし実際の英米では疑問文と否定文でのみ助動詞 need が使われるのが一般的である（青チャート、桐原ファクト）。 このような制限が助動詞 need にあるため、実のところ、あまり信用頻度は高くない、・・・というのが桐原ファクトの見解。 助動詞 need の否定形は need not または needn't であり（青チャ－ト）、つまり「 need not ＋動詞の原型」のような形になる。 また、助動詞 need に過去形は無い（青チャ、インスパ）。また、主語が三人称単数でも、助動詞 need には sはつかず、needのまま（青チャ）。 もし、過去の必要性について言いたい場合、単に、本動詞 「need to不定詞」を使えばいい（ジーニアス、青チャ、インスパイア）。 なお、本動詞 need の否定文や疑問文は、単に中学英文法と同様に I didn't need to 不定詞 や Did you need to 不定詞 ? を使えばいいだけである。 なお、完了形との組み合わせ「 need not have ＋過去分詞」だと、「～する必要はなかったのに」（＋「しかし実際は～してしまった」）という意味になる（ジーニアス、インスパイア）。 ※ インスパイアに「実際は～してしまった」の説明あり。 == dare == 助動詞としては、2つの慣用文がある。 How dare say ～？　「よくも～できたものだね」 という苛立ち（いらだち）をあらわす。 I dare say ～. 「たぶん～だろう」「おそらく～だろう」 sayのあとに接続詞 that は続かない（インスパイア）。 I daresay ～ という一語でdareとsayを縮めた言い回しもある（インスパイア、ブレイクスルー）。 dare の用法は、あまり論理的ではない。ほか、助動詞 dareに過去形 dared もあるとされているが、現代ではマレ（青チャート）。 そのほか、 Bod dare not propose to her. 「ボブは彼女にプロポーズする勇気がない」 のように、否定文や疑問文で dare が使われることがある。 だが、この場合の dare は「勇気のある」の意味なので、助動詞を使わずとも courage や brave などをつかった言い表すこともできて、むしろ英米では口語には courage などの言い回しのほうが多いのが実態とのこと（エバーグリーン）。 さて、助動詞以外にも、本動詞としての dare の用法があり、上記２つの「How dare」「I dare say（または daresay）」慣用表現以外の場合では、本動詞としてdareをつかうことのほうが一般的であり（ジーニアス）、 He dares（または dared） to ～ 「彼はずうずうしくも～する（した）」 のように使うこともある（青チャ）。 == ought to == ought to は、助動詞 should と同じような意味として紹介されることもある。だが、実際には should よりも、やや意味が強い。 ought to には、「～すべきである」という義務・当然の意味や、「～するはずだ」「～にちがいない」という強い推定・見込みの意味（インスパイア、青チャ）がある。 義務の強さは、 must ＞ ought to ＞ should である（ジーニアス）。 ought は助動詞であるが、to不定詞とともに使われる。 なお、ought to の否定形は ought not to ～ である（エバー、青）。 oughtn't to ～ という短縮形の否定もある（青）。 gimo疑問文は、たとえば「私は～すべきでしょうか？」なら Ought I to 不定詞 ～? の語順になる（青、ファクト）。 つまり、 Ought 主語 to 不定詞 ～? の語順。 == had better == had better 「～したほうがいい」は、字面だけなら「推奨」の意味だが、文脈によっては「命令」や「脅し」の意味に受け取られる場合がある。 had better には「そうしないと（or）、困った事になるぞ」という含みがあると感じられる場合があるから、である（桐原ファクト、）。 とくに、主語が you の場合、命令などの意味に受け取られやすいので、注意が必要（エバー）。 このため、 I think you had better ～　のように「I think 」や maybe などをつけて、意味をやわらげる場合もよくある。 had better の否定は 「had better not 動詞の原型」である（エバ、ジーニ）。 :※ 完了形と混同してか、had better なのに had の後ろに not を置くミスが学生に多い（エバ）。 「It would be better for you to 不定詞」でも、意味をやわらげられる（青チャート、インスパ、ブレイク）ので、目上の人にはこの言い回しが良いとされる（青チャ）。 青チャートいわく、「 It might be better for you to 不定詞」や「I would suggest (that)」 などでも「～するのが良いでしょう」の意味で言い換えできる、とのこと（青チャ）。 s5v4cmjwidgpxqipqvvrjcuqslc8o1m 205942 205941 2022-07-28T10:28:54Z すじにくシチュー 12058 /* had better */ wikitext text/x-wiki == must == === 勧誘 must === must には、強い勧誘を意味する用法もある（インスパイア、桐原ファクトブック、ジーニアス）。 You must ～. 「ぜひ～してください」「ぜひ～したほうがいい」 のような意味。 青チャートには書いていない。（あまり重要視してないのだろう。） 欧米人は、この手の、外国人には分かりづらい、やや飛躍気味の表現をすることもよくある。 :※ 飛躍気味とは、たとえば最近の俗語の例では、英米人の近年の若者などの用法で、すばらしい絵や文芸を見たときに、「その絵を消してくれ」なんていう表現も最近の英語では良く使われるという。どうやら「素晴らしすぎて、魅了されて、頭がおかしくなってしまいそうだ」→「だから消してくれ」という意味らしいのだが、しかし事情が知らない外国人が聞くと、単にその絵や文芸に不満があるかと誤解されかねない。しかし、英語は世界の覇権言語なので、外国人からの誤解を気にする必要も無い。日本人からすれば、まったく、英米人はうらやましい限りである。 この 勧誘の must を紹介しているインスパイア、ジーニアスも、コラム的に紹介しているだけである。（桐原ファクトのみ、本文で紹介。） :※ 昔から教育評論でよく言われる、英語教育の隠れた目的のひとつとして、誤解の恐れの少ない論理的な文章の書き方の教育を教える、という目的がある。文科省や国立大学などは、中立性などの理由で、「論理的な日本語の書き方はこうあるべきし」とは宣言できないので、仕方なく英文法など外国語を使って論理的な文章の書き方を教えようとしている、などとは昔はよく評論されたものである（もっとも、最近の英語教育では会話重視などで、そういう論理性の教育目的は雲散霧消してしまったが）。そういう論理的な文章の書き方の教育としては、勧誘 must やら上記例の「消してくれ」のような飛躍気味の用法は、嫌われるだろうから、大学入試などに勧誘の must などが出る可能性は低いかもしれない。 == 確信「ちがいない」 must の否定 == 「～にちがいない」という強い確認の意味での must の否定は、 cannot 「～はずがない」である（ジーニアス、インスパイア、青チャート）。 なぜそうかといわれても、そうだと決まってる。英米人がそういう使い方をしているので、合わせるしかない。 :※ これまた、あまり論理的でないので、おそらく入試では問われづらいだろう。たとえば桐原ファクトでは、must の項目では、確信の否定 cannot を無視しており、非紹介である。なお、桐原でも can の側で cannot「～はずがない」を説明しており、可能性 can の否定として cannot「～はずがない」 という用法を説明するというのが桐原ファクトの理論構成である。 cannot や can't と言った場合、単に「～できない」という可能性を否定するだけの用法もあるが（インスパイア　can側）、それとは別に「～のはずがない」という強めの感情的色彩をおびた「否定の確信」な意味の用法の場合もある（桐原ファクト、ジーニアス）。 == Can you ? == 英語では、相手に能力を直接聞くのは、失礼に当たると見なされている場合もある。 たとえば、 Can you speak Japanese? は、背景として、「あなたは日本語を話せないといけない」と思われることもある（インスパイア、ジーニアス）。このため、canを使わずに Do you speak Japanese? と聞くのが良いとされている（ジーニアス）。 一方、話し手が自分の語学の能力を「私は～できます」と言う場合は、なるべく be able to よりも canを使うほうが謙遜気味で礼儀正しいとされており、つまり I can のほうが良いとされている（ジーニアス）。I のあとに be able to を使うと、英米では能力自慢のように聞こえるらしい（ジーニアス）。 can youが無礼なのに I can が礼儀正しいのは意味不明だが、しかし覇権国家の英米人がそう使い分けているので、英語学ではそう合わせるしかない。うらやましい。所詮、語学は暗記科目であり、「理屈と膏薬はどこにでもつく」（日本のことわざ）である。 また、派生的にか、可能性のcanは疑問文では、強めの疑いや、おどろきや当惑などの意味をもつこともよくある（青チャート、インスパイア）。参考書によくある典型的な例文だが Can the rumor be true? 「そのウワサは本当だろうか？」 という疑問文では、そのような、強めの疑いや、おどろきなどの意味がある。・ さて、can は、今後も通用する能力や可能性について言うので、単に一回だけのことに「昨日は～できた」みたいに言う場合には can や could を使わない（ジーニアス、青チャート）。 1回だけ「～できた」場合には、 be able to や 「managed to不定詞」 や succeed in ～ing などを使う（青チャート、インスパイア）。 また、とくに能力などを強調するのでなければ、単に過去形だけを使って1回だけできたことを表現してもいい（ジーニアス）。 なお、否定文や疑問文の場合は could を使っても良く、つまり couldn't や wasn't（または weren't） able to でもいい（インスパイア）。 ただし、こういう細かい使い分けよりも、入試に出るのは、構文 cannot help ～ing 「～せざるを得ない」 cannot help but ＋動詞の原型 「～せざるを得ない」 cannot but ＋動詞の原型 などだろう（インスパイア、桐原ファクトブック）。 90年代、こういう二重否定的な構文が（中学範囲ではなく）高校範囲だった過去がある。 cannot ～ too ○○ 「いくら～しすぎても○○しすぎることはない」 という反語的な表現も、90年代の典型的な高校英文法の範囲であった。 そのほか、「ときに　～することがある」と好ましくない事を言う場合に can を使うことがある。ジーニアスいわく「風邪は時に重い病気につながることがある」とか、青チャートいわく「そういう事故はときどき起こりうるものだ」で can を使っている。 だが、これとは逆に思える用法もインスパイアにあり、「can はもともと備わっている能力を表す」として「be able to は一時的な能力を表す」などという用法もある。 ※ このように、助動詞まわりは、あまり規則的ではなく、またやや口語的であり、あまり日本の大学入試対策としては深入りする必要が無いだろう。上述したが cannot help ～ ing のような構文を覚えることを優先すべきである。 == 助動詞 need == 本動詞 need とは別に、助動詞 need というのがあり、 「need ＋動詞の原型」の形で使う。 助動詞 need は主にイギリス英語である。 参考書では平叙文に助動詞 need が使われることもあるが（ジーニアス）、しかし実際の英米では疑問文と否定文でのみ助動詞 need が使われるのが一般的である（青チャート、桐原ファクト）。 このような制限が助動詞 need にあるため、実のところ、あまり信用頻度は高くない、・・・というのが桐原ファクトの見解。 助動詞 need の否定形は need not または needn't であり（青チャ－ト）、つまり「 need not ＋動詞の原型」のような形になる。 また、助動詞 need に過去形は無い（青チャ、インスパ）。また、主語が三人称単数でも、助動詞 need には sはつかず、needのまま（青チャ）。 もし、過去の必要性について言いたい場合、単に、本動詞 「need to不定詞」を使えばいい（ジーニアス、青チャ、インスパイア）。 なお、本動詞 need の否定文や疑問文は、単に中学英文法と同様に I didn't need to 不定詞 や Did you need to 不定詞 ? を使えばいいだけである。 なお、完了形との組み合わせ「 need not have ＋過去分詞」だと、「～する必要はなかったのに」（＋「しかし実際は～してしまった」）という意味になる（ジーニアス、インスパイア）。 ※ インスパイアに「実際は～してしまった」の説明あり。 == dare == 助動詞としては、2つの慣用文がある。 How dare say ～？　「よくも～できたものだね」 という苛立ち（いらだち）をあらわす。 I dare say ～. 「たぶん～だろう」「おそらく～だろう」 sayのあとに接続詞 that は続かない（インスパイア）。 I daresay ～ という一語でdareとsayを縮めた言い回しもある（インスパイア、ブレイクスルー）。 dare の用法は、あまり論理的ではない。ほか、助動詞 dareに過去形 dared もあるとされているが、現代ではマレ（青チャート）。 そのほか、 Bod dare not propose to her. 「ボブは彼女にプロポーズする勇気がない」 のように、否定文や疑問文で dare が使われることがある。 だが、この場合の dare は「勇気のある」の意味なので、助動詞を使わずとも courage や brave などをつかった言い表すこともできて、むしろ英米では口語には courage などの言い回しのほうが多いのが実態とのこと（エバーグリーン）。 さて、助動詞以外にも、本動詞としての dare の用法があり、上記２つの「How dare」「I dare say（または daresay）」慣用表現以外の場合では、本動詞としてdareをつかうことのほうが一般的であり（ジーニアス）、 He dares（または dared） to ～ 「彼はずうずうしくも～する（した）」 のように使うこともある（青チャ）。 == ought to == ought to は、助動詞 should と同じような意味として紹介されることもある。だが、実際には should よりも、やや意味が強い。 ought to には、「～すべきである」という義務・当然の意味や、「～するはずだ」「～にちがいない」という強い推定・見込みの意味（インスパイア、青チャ）がある。 義務の強さは、 must ＞ ought to ＞ should である（ジーニアス）。 ought は助動詞であるが、to不定詞とともに使われる。 なお、ought to の否定形は ought not to ～ である（エバー、青）。 oughtn't to ～ という短縮形の否定もある（青）。 gimo疑問文は、たとえば「私は～すべきでしょうか？」なら Ought I to 不定詞 ～? の語順になる（青、ファクト）。 つまり、 Ought 主語 to 不定詞 ～? の語順。 == had better == had better 「～したほうがいい」は、字面だけなら「推奨」の意味だが、文脈によっては「命令」や「脅し」の意味に受け取られる場合がある。 had better には「そうしないと（or）、困った事になるぞ」という含みがあると感じられる場合があるから、である（桐原ファクト、）。 とくに、主語が you の場合、命令などの意味に受け取られやすいので、注意が必要（エバー）。 このため、 I think you had better ～　のように「I think 」や maybe などをつけて、意味をやわらげる場合もよくある。 had better の否定は 「had better not 動詞の原型」である（エバ、ジーニ）。 :※ 完了形と混同してか、had better なのに had の後ろに not を置くミスが学生に多い（エバ）。 「It would be better for you to 不定詞」でも、意味をやわらげられる（青チャート、インスパ、ブレイク）ので、目上の人にはこの言い回しが良いとされる（青チャ）。 青チャートいわく、「 It might be better for you to 不定詞」や「I would suggest (that)」 などでも「～するのが良いでしょう」の意味で言い換えできる、とのこと（青チャ）。 言い換え表現のほうでは、動詞の前にtoがついてto不定詞になっているのに注意。 なお、口語では You'd better や I'd better のように、よくhad を 'd と省略する（青チャ、ブレイク）。 i9itnzvktqsdcev0lhx2mgvql4xnwh3 205943 205942 2022-07-28T10:34:57Z すじにくシチュー 12058 /* had better */ wikitext text/x-wiki == must == === 勧誘 must === must には、強い勧誘を意味する用法もある（インスパイア、桐原ファクトブック、ジーニアス）。 You must ～. 「ぜひ～してください」「ぜひ～したほうがいい」 のような意味。 青チャートには書いていない。（あまり重要視してないのだろう。） 欧米人は、この手の、外国人には分かりづらい、やや飛躍気味の表現をすることもよくある。 :※ 飛躍気味とは、たとえば最近の俗語の例では、英米人の近年の若者などの用法で、すばらしい絵や文芸を見たときに、「その絵を消してくれ」なんていう表現も最近の英語では良く使われるという。どうやら「素晴らしすぎて、魅了されて、頭がおかしくなってしまいそうだ」→「だから消してくれ」という意味らしいのだが、しかし事情が知らない外国人が聞くと、単にその絵や文芸に不満があるかと誤解されかねない。しかし、英語は世界の覇権言語なので、外国人からの誤解を気にする必要も無い。日本人からすれば、まったく、英米人はうらやましい限りである。 この 勧誘の must を紹介しているインスパイア、ジーニアスも、コラム的に紹介しているだけである。（桐原ファクトのみ、本文で紹介。） :※ 昔から教育評論でよく言われる、英語教育の隠れた目的のひとつとして、誤解の恐れの少ない論理的な文章の書き方の教育を教える、という目的がある。文科省や国立大学などは、中立性などの理由で、「論理的な日本語の書き方はこうあるべきし」とは宣言できないので、仕方なく英文法など外国語を使って論理的な文章の書き方を教えようとしている、などとは昔はよく評論されたものである（もっとも、最近の英語教育では会話重視などで、そういう論理性の教育目的は雲散霧消してしまったが）。そういう論理的な文章の書き方の教育としては、勧誘 must やら上記例の「消してくれ」のような飛躍気味の用法は、嫌われるだろうから、大学入試などに勧誘の must などが出る可能性は低いかもしれない。 == 確信「ちがいない」 must の否定 == 「～にちがいない」という強い確認の意味での must の否定は、 cannot 「～はずがない」である（ジーニアス、インスパイア、青チャート）。 なぜそうかといわれても、そうだと決まってる。英米人がそういう使い方をしているので、合わせるしかない。 :※ これまた、あまり論理的でないので、おそらく入試では問われづらいだろう。たとえば桐原ファクトでは、must の項目では、確信の否定 cannot を無視しており、非紹介である。なお、桐原でも can の側で cannot「～はずがない」を説明しており、可能性 can の否定として cannot「～はずがない」 という用法を説明するというのが桐原ファクトの理論構成である。 cannot や can't と言った場合、単に「～できない」という可能性を否定するだけの用法もあるが（インスパイア　can側）、それとは別に「～のはずがない」という強めの感情的色彩をおびた「否定の確信」な意味の用法の場合もある（桐原ファクト、ジーニアス）。 == Can you ? == 英語では、相手に能力を直接聞くのは、失礼に当たると見なされている場合もある。 たとえば、 Can you speak Japanese? は、背景として、「あなたは日本語を話せないといけない」と思われることもある（インスパイア、ジーニアス）。このため、canを使わずに Do you speak Japanese? と聞くのが良いとされている（ジーニアス）。 一方、話し手が自分の語学の能力を「私は～できます」と言う場合は、なるべく be able to よりも canを使うほうが謙遜気味で礼儀正しいとされており、つまり I can のほうが良いとされている（ジーニアス）。I のあとに be able to を使うと、英米では能力自慢のように聞こえるらしい（ジーニアス）。 can youが無礼なのに I can が礼儀正しいのは意味不明だが、しかし覇権国家の英米人がそう使い分けているので、英語学ではそう合わせるしかない。うらやましい。所詮、語学は暗記科目であり、「理屈と膏薬はどこにでもつく」（日本のことわざ）である。 また、派生的にか、可能性のcanは疑問文では、強めの疑いや、おどろきや当惑などの意味をもつこともよくある（青チャート、インスパイア）。参考書によくある典型的な例文だが Can the rumor be true? 「そのウワサは本当だろうか？」 という疑問文では、そのような、強めの疑いや、おどろきなどの意味がある。・ さて、can は、今後も通用する能力や可能性について言うので、単に一回だけのことに「昨日は～できた」みたいに言う場合には can や could を使わない（ジーニアス、青チャート）。 1回だけ「～できた」場合には、 be able to や 「managed to不定詞」 や succeed in ～ing などを使う（青チャート、インスパイア）。 また、とくに能力などを強調するのでなければ、単に過去形だけを使って1回だけできたことを表現してもいい（ジーニアス）。 なお、否定文や疑問文の場合は could を使っても良く、つまり couldn't や wasn't（または weren't） able to でもいい（インスパイア）。 ただし、こういう細かい使い分けよりも、入試に出るのは、構文 cannot help ～ing 「～せざるを得ない」 cannot help but ＋動詞の原型 「～せざるを得ない」 cannot but ＋動詞の原型 などだろう（インスパイア、桐原ファクトブック）。 90年代、こういう二重否定的な構文が（中学範囲ではなく）高校範囲だった過去がある。 cannot ～ too ○○ 「いくら～しすぎても○○しすぎることはない」 という反語的な表現も、90年代の典型的な高校英文法の範囲であった。 そのほか、「ときに　～することがある」と好ましくない事を言う場合に can を使うことがある。ジーニアスいわく「風邪は時に重い病気につながることがある」とか、青チャートいわく「そういう事故はときどき起こりうるものだ」で can を使っている。 だが、これとは逆に思える用法もインスパイアにあり、「can はもともと備わっている能力を表す」として「be able to は一時的な能力を表す」などという用法もある。 ※ このように、助動詞まわりは、あまり規則的ではなく、またやや口語的であり、あまり日本の大学入試対策としては深入りする必要が無いだろう。上述したが cannot help ～ ing のような構文を覚えることを優先すべきである。 == 助動詞 need == 本動詞 need とは別に、助動詞 need というのがあり、 「need ＋動詞の原型」の形で使う。 助動詞 need は主にイギリス英語である。 参考書では平叙文に助動詞 need が使われることもあるが（ジーニアス）、しかし実際の英米では疑問文と否定文でのみ助動詞 need が使われるのが一般的である（青チャート、桐原ファクト）。 このような制限が助動詞 need にあるため、実のところ、あまり信用頻度は高くない、・・・というのが桐原ファクトの見解。 助動詞 need の否定形は need not または needn't であり（青チャ－ト）、つまり「 need not ＋動詞の原型」のような形になる。 また、助動詞 need に過去形は無い（青チャ、インスパ）。また、主語が三人称単数でも、助動詞 need には sはつかず、needのまま（青チャ）。 もし、過去の必要性について言いたい場合、単に、本動詞 「need to不定詞」を使えばいい（ジーニアス、青チャ、インスパイア）。 なお、本動詞 need の否定文や疑問文は、単に中学英文法と同様に I didn't need to 不定詞 や Did you need to 不定詞 ? を使えばいいだけである。 なお、完了形との組み合わせ「 need not have ＋過去分詞」だと、「～する必要はなかったのに」（＋「しかし実際は～してしまった」）という意味になる（ジーニアス、インスパイア）。 ※ インスパイアに「実際は～してしまった」の説明あり。 == dare == 助動詞としては、2つの慣用文がある。 How dare say ～？　「よくも～できたものだね」 という苛立ち（いらだち）をあらわす。 I dare say ～. 「たぶん～だろう」「おそらく～だろう」 sayのあとに接続詞 that は続かない（インスパイア）。 I daresay ～ という一語でdareとsayを縮めた言い回しもある（インスパイア、ブレイクスルー）。 dare の用法は、あまり論理的ではない。ほか、助動詞 dareに過去形 dared もあるとされているが、現代ではマレ（青チャート）。 そのほか、 Bod dare not propose to her. 「ボブは彼女にプロポーズする勇気がない」 のように、否定文や疑問文で dare が使われることがある。 だが、この場合の dare は「勇気のある」の意味なので、助動詞を使わずとも courage や brave などをつかった言い表すこともできて、むしろ英米では口語には courage などの言い回しのほうが多いのが実態とのこと（エバーグリーン）。 さて、助動詞以外にも、本動詞としての dare の用法があり、上記２つの「How dare」「I dare say（または daresay）」慣用表現以外の場合では、本動詞としてdareをつかうことのほうが一般的であり（ジーニアス）、 He dares（または dared） to ～ 「彼はずうずうしくも～する（した）」 のように使うこともある（青チャ）。 == ought to == ought to は、助動詞 should と同じような意味として紹介されることもある。だが、実際には should よりも、やや意味が強い。 ought to には、「～すべきである」という義務・当然の意味や、「～するはずだ」「～にちがいない」という強い推定・見込みの意味（インスパイア、青チャ）がある。 義務の強さは、 must ＞ ought to ＞ should である（ジーニアス）。 ought は助動詞であるが、to不定詞とともに使われる。 なお、ought to の否定形は ought not to ～ である（エバー、青）。 oughtn't to ～ という短縮形の否定もある（青）。 gimo疑問文は、たとえば「私は～すべきでしょうか？」なら Ought I to 不定詞 ～? の語順になる（青、ファクト）。 つまり、 Ought 主語 to 不定詞 ～? の語順。 == had better == had better 「～したほうがいい」は、字面だけなら「推奨」の意味だが、文脈によっては「命令」や「脅し」の意味に受け取られる場合がある。 had better には「そうしないと（or）、困った事になるぞ」という含みがあると感じられる場合があるから、である（桐原ファクト、）。 とくに、主語が you の場合、命令などの意味に受け取られやすいので、注意が必要（エバー）。 このため、 I think you had better ～　のように「I think 」や maybe などをつけて、意味をやわらげる場合もよくある。 had better の否定は 「had better not 動詞の原型」である（エバ、ジーニ）。 :※ 完了形と混同してか、had better なのに had の後ろに not を置くミスが学生に多い（エバ）。 「It would be better for you to 不定詞」でも、意味をやわらげられる（青チャート、インスパ、ブレイク）ので、目上の人にはこの言い回しが良いとされる（青チャ）。 青チャートいわく、「 It might be better for you to 不定詞」や「I would suggest (that)」 などでも「～するのが良いでしょう」の意味で言い換えできる、とのこと（青チャ）。 言い換え表現のほうでは、動詞の前にtoがついてto不定詞になっているのに注意。 なお、口語では You'd better や I'd better のように、よくhad を 'd と省略する（青チャ、ブレイク）。 疑問文の語順については、インスパイアと青チャート以外、言及していない。説明の簡単のため主語を I とすると、「～したほうが良いですか？」は Had I better ～？ または Hadn't I better ～？ とのこと（インスパイア）。 いっぽう、 Han I better not ～？　「～しないほうが良いですか？」 とのこと（インスパイア）。 青チャートいわく、英語では実際によく使われるのは、 Hadn't I better ～？　「～しないほうが良いですか？」 という言い回しとのこと（青チャ）。 oa116ihu9nmk1439y1r0a4ccuiomhwp 205944 205943 2022-07-28T10:37:03Z すじにくシチュー 12058 /* 助動詞 need */ wikitext text/x-wiki == must == === 勧誘 must === must には、強い勧誘を意味する用法もある（インスパイア、桐原ファクトブック、ジーニアス）。 You must ～. 「ぜひ～してください」「ぜひ～したほうがいい」 のような意味。 青チャートには書いていない。（あまり重要視してないのだろう。） 欧米人は、この手の、外国人には分かりづらい、やや飛躍気味の表現をすることもよくある。 :※ 飛躍気味とは、たとえば最近の俗語の例では、英米人の近年の若者などの用法で、すばらしい絵や文芸を見たときに、「その絵を消してくれ」なんていう表現も最近の英語では良く使われるという。どうやら「素晴らしすぎて、魅了されて、頭がおかしくなってしまいそうだ」→「だから消してくれ」という意味らしいのだが、しかし事情が知らない外国人が聞くと、単にその絵や文芸に不満があるかと誤解されかねない。しかし、英語は世界の覇権言語なので、外国人からの誤解を気にする必要も無い。日本人からすれば、まったく、英米人はうらやましい限りである。 この 勧誘の must を紹介しているインスパイア、ジーニアスも、コラム的に紹介しているだけである。（桐原ファクトのみ、本文で紹介。） :※ 昔から教育評論でよく言われる、英語教育の隠れた目的のひとつとして、誤解の恐れの少ない論理的な文章の書き方の教育を教える、という目的がある。文科省や国立大学などは、中立性などの理由で、「論理的な日本語の書き方はこうあるべきし」とは宣言できないので、仕方なく英文法など外国語を使って論理的な文章の書き方を教えようとしている、などとは昔はよく評論されたものである（もっとも、最近の英語教育では会話重視などで、そういう論理性の教育目的は雲散霧消してしまったが）。そういう論理的な文章の書き方の教育としては、勧誘 must やら上記例の「消してくれ」のような飛躍気味の用法は、嫌われるだろうから、大学入試などに勧誘の must などが出る可能性は低いかもしれない。 == 確信「ちがいない」 must の否定 == 「～にちがいない」という強い確認の意味での must の否定は、 cannot 「～はずがない」である（ジーニアス、インスパイア、青チャート）。 なぜそうかといわれても、そうだと決まってる。英米人がそういう使い方をしているので、合わせるしかない。 :※ これまた、あまり論理的でないので、おそらく入試では問われづらいだろう。たとえば桐原ファクトでは、must の項目では、確信の否定 cannot を無視しており、非紹介である。なお、桐原でも can の側で cannot「～はずがない」を説明しており、可能性 can の否定として cannot「～はずがない」 という用法を説明するというのが桐原ファクトの理論構成である。 cannot や can't と言った場合、単に「～できない」という可能性を否定するだけの用法もあるが（インスパイア　can側）、それとは別に「～のはずがない」という強めの感情的色彩をおびた「否定の確信」な意味の用法の場合もある（桐原ファクト、ジーニアス）。 == Can you ? == 英語では、相手に能力を直接聞くのは、失礼に当たると見なされている場合もある。 たとえば、 Can you speak Japanese? は、背景として、「あなたは日本語を話せないといけない」と思われることもある（インスパイア、ジーニアス）。このため、canを使わずに Do you speak Japanese? と聞くのが良いとされている（ジーニアス）。 一方、話し手が自分の語学の能力を「私は～できます」と言う場合は、なるべく be able to よりも canを使うほうが謙遜気味で礼儀正しいとされており、つまり I can のほうが良いとされている（ジーニアス）。I のあとに be able to を使うと、英米では能力自慢のように聞こえるらしい（ジーニアス）。 can youが無礼なのに I can が礼儀正しいのは意味不明だが、しかし覇権国家の英米人がそう使い分けているので、英語学ではそう合わせるしかない。うらやましい。所詮、語学は暗記科目であり、「理屈と膏薬はどこにでもつく」（日本のことわざ）である。 また、派生的にか、可能性のcanは疑問文では、強めの疑いや、おどろきや当惑などの意味をもつこともよくある（青チャート、インスパイア）。参考書によくある典型的な例文だが Can the rumor be true? 「そのウワサは本当だろうか？」 という疑問文では、そのような、強めの疑いや、おどろきなどの意味がある。・ さて、can は、今後も通用する能力や可能性について言うので、単に一回だけのことに「昨日は～できた」みたいに言う場合には can や could を使わない（ジーニアス、青チャート）。 1回だけ「～できた」場合には、 be able to や 「managed to不定詞」 や succeed in ～ing などを使う（青チャート、インスパイア）。 また、とくに能力などを強調するのでなければ、単に過去形だけを使って1回だけできたことを表現してもいい（ジーニアス）。 なお、否定文や疑問文の場合は could を使っても良く、つまり couldn't や wasn't（または weren't） able to でもいい（インスパイア）。 ただし、こういう細かい使い分けよりも、入試に出るのは、構文 cannot help ～ing 「～せざるを得ない」 cannot help but ＋動詞の原型 「～せざるを得ない」 cannot but ＋動詞の原型 などだろう（インスパイア、桐原ファクトブック）。 90年代、こういう二重否定的な構文が（中学範囲ではなく）高校範囲だった過去がある。 cannot ～ too ○○ 「いくら～しすぎても○○しすぎることはない」 という反語的な表現も、90年代の典型的な高校英文法の範囲であった。 そのほか、「ときに　～することがある」と好ましくない事を言う場合に can を使うことがある。ジーニアスいわく「風邪は時に重い病気につながることがある」とか、青チャートいわく「そういう事故はときどき起こりうるものだ」で can を使っている。 だが、これとは逆に思える用法もインスパイアにあり、「can はもともと備わっている能力を表す」として「be able to は一時的な能力を表す」などという用法もある。 ※ このように、助動詞まわりは、あまり規則的ではなく、またやや口語的であり、あまり日本の大学入試対策としては深入りする必要が無いだろう。上述したが cannot help ～ ing のような構文を覚えることを優先すべきである。 == 助動詞 need == 本動詞 need とは別に、助動詞 need というのがあり、 「need ＋動詞の原型」の形で使う。 助動詞 need は主にイギリス英語である。 参考書では平叙文に助動詞 need が使われることもあるが（ジーニアス）、しかし実際の英米では疑問文と否定文でのみ助動詞 need が使われるのが一般的である（青チャート、桐原ファクト）。 このような制限が助動詞 need にあるため、実のところ、あまり信用頻度は高くない、・・・というのが桐原ファクトの見解。 助動詞 need の否定形は need not または needn't であり（青チャ－ト）、つまり「 need not ＋動詞の原型」のような形になる。 また、助動詞 need に過去形は無い（青チャ、インスパ）。また、主語が三人称単数でも、助動詞 need には sはつかず、needのまま（青チャ）。 もし、過去の必要性について言いたい場合、単に、本動詞 「need to不定詞」を使えばいい（ジーニアス、青チャ、インスパイア）。 なお、本動詞 need の否定文や疑問文は、単に中学英文法と同様に I didn't need to 不定詞 や Did you need to 不定詞 ? を使えばいいだけである。 なお、完了形との組み合わせ「 need not have ＋過去分詞」だと、「～する必要はなかったのに」（＋「しかし実際は～してしまった」）という意味になる（ジーニアス、インスパイア、桐原ファクト）。 ※ インスパイア・桐原ファクトに「実際は～してしまった」の説明あり。 == dare == 助動詞としては、2つの慣用文がある。 How dare say ～？　「よくも～できたものだね」 という苛立ち（いらだち）をあらわす。 I dare say ～. 「たぶん～だろう」「おそらく～だろう」 sayのあとに接続詞 that は続かない（インスパイア）。 I daresay ～ という一語でdareとsayを縮めた言い回しもある（インスパイア、ブレイクスルー）。 dare の用法は、あまり論理的ではない。ほか、助動詞 dareに過去形 dared もあるとされているが、現代ではマレ（青チャート）。 そのほか、 Bod dare not propose to her. 「ボブは彼女にプロポーズする勇気がない」 のように、否定文や疑問文で dare が使われることがある。 だが、この場合の dare は「勇気のある」の意味なので、助動詞を使わずとも courage や brave などをつかった言い表すこともできて、むしろ英米では口語には courage などの言い回しのほうが多いのが実態とのこと（エバーグリーン）。 さて、助動詞以外にも、本動詞としての dare の用法があり、上記２つの「How dare」「I dare say（または daresay）」慣用表現以外の場合では、本動詞としてdareをつかうことのほうが一般的であり（ジーニアス）、 He dares（または dared） to ～ 「彼はずうずうしくも～する（した）」 のように使うこともある（青チャ）。 == ought to == ought to は、助動詞 should と同じような意味として紹介されることもある。だが、実際には should よりも、やや意味が強い。 ought to には、「～すべきである」という義務・当然の意味や、「～するはずだ」「～にちがいない」という強い推定・見込みの意味（インスパイア、青チャ）がある。 義務の強さは、 must ＞ ought to ＞ should である（ジーニアス）。 ought は助動詞であるが、to不定詞とともに使われる。 なお、ought to の否定形は ought not to ～ である（エバー、青）。 oughtn't to ～ という短縮形の否定もある（青）。 gimo疑問文は、たとえば「私は～すべきでしょうか？」なら Ought I to 不定詞 ～? の語順になる（青、ファクト）。 つまり、 Ought 主語 to 不定詞 ～? の語順。 == had better == had better 「～したほうがいい」は、字面だけなら「推奨」の意味だが、文脈によっては「命令」や「脅し」の意味に受け取られる場合がある。 had better には「そうしないと（or）、困った事になるぞ」という含みがあると感じられる場合があるから、である（桐原ファクト、）。 とくに、主語が you の場合、命令などの意味に受け取られやすいので、注意が必要（エバー）。 このため、 I think you had better ～　のように「I think 」や maybe などをつけて、意味をやわらげる場合もよくある。 had better の否定は 「had better not 動詞の原型」である（エバ、ジーニ）。 :※ 完了形と混同してか、had better なのに had の後ろに not を置くミスが学生に多い（エバ）。 「It would be better for you to 不定詞」でも、意味をやわらげられる（青チャート、インスパ、ブレイク）ので、目上の人にはこの言い回しが良いとされる（青チャ）。 青チャートいわく、「 It might be better for you to 不定詞」や「I would suggest (that)」 などでも「～するのが良いでしょう」の意味で言い換えできる、とのこと（青チャ）。 言い換え表現のほうでは、動詞の前にtoがついてto不定詞になっているのに注意。 なお、口語では You'd better や I'd better のように、よくhad を 'd と省略する（青チャ、ブレイク）。 疑問文の語順については、インスパイアと青チャート以外、言及していない。説明の簡単のため主語を I とすると、「～したほうが良いですか？」は Had I better ～？ または Hadn't I better ～？ とのこと（インスパイア）。 いっぽう、 Han I better not ～？　「～しないほうが良いですか？」 とのこと（インスパイア）。 青チャートいわく、英語では実際によく使われるのは、 Hadn't I better ～？　「～しないほうが良いですか？」 という言い回しとのこと（青チャ）。 mtu4b42lm9lky2ebnd1dq399jl6umfo 205945 205944 2022-07-28T10:40:13Z すじにくシチュー 12058 /* 助動詞 need */ wikitext text/x-wiki == must == === 勧誘 must === must には、強い勧誘を意味する用法もある（インスパイア、桐原ファクトブック、ジーニアス）。 You must ～. 「ぜひ～してください」「ぜひ～したほうがいい」 のような意味。 青チャートには書いていない。（あまり重要視してないのだろう。） 欧米人は、この手の、外国人には分かりづらい、やや飛躍気味の表現をすることもよくある。 :※ 飛躍気味とは、たとえば最近の俗語の例では、英米人の近年の若者などの用法で、すばらしい絵や文芸を見たときに、「その絵を消してくれ」なんていう表現も最近の英語では良く使われるという。どうやら「素晴らしすぎて、魅了されて、頭がおかしくなってしまいそうだ」→「だから消してくれ」という意味らしいのだが、しかし事情が知らない外国人が聞くと、単にその絵や文芸に不満があるかと誤解されかねない。しかし、英語は世界の覇権言語なので、外国人からの誤解を気にする必要も無い。日本人からすれば、まったく、英米人はうらやましい限りである。 この 勧誘の must を紹介しているインスパイア、ジーニアスも、コラム的に紹介しているだけである。（桐原ファクトのみ、本文で紹介。） :※ 昔から教育評論でよく言われる、英語教育の隠れた目的のひとつとして、誤解の恐れの少ない論理的な文章の書き方の教育を教える、という目的がある。文科省や国立大学などは、中立性などの理由で、「論理的な日本語の書き方はこうあるべきし」とは宣言できないので、仕方なく英文法など外国語を使って論理的な文章の書き方を教えようとしている、などとは昔はよく評論されたものである（もっとも、最近の英語教育では会話重視などで、そういう論理性の教育目的は雲散霧消してしまったが）。そういう論理的な文章の書き方の教育としては、勧誘 must やら上記例の「消してくれ」のような飛躍気味の用法は、嫌われるだろうから、大学入試などに勧誘の must などが出る可能性は低いかもしれない。 == 確信「ちがいない」 must の否定 == 「～にちがいない」という強い確認の意味での must の否定は、 cannot 「～はずがない」である（ジーニアス、インスパイア、青チャート）。 なぜそうかといわれても、そうだと決まってる。英米人がそういう使い方をしているので、合わせるしかない。 :※ これまた、あまり論理的でないので、おそらく入試では問われづらいだろう。たとえば桐原ファクトでは、must の項目では、確信の否定 cannot を無視しており、非紹介である。なお、桐原でも can の側で cannot「～はずがない」を説明しており、可能性 can の否定として cannot「～はずがない」 という用法を説明するというのが桐原ファクトの理論構成である。 cannot や can't と言った場合、単に「～できない」という可能性を否定するだけの用法もあるが（インスパイア　can側）、それとは別に「～のはずがない」という強めの感情的色彩をおびた「否定の確信」な意味の用法の場合もある（桐原ファクト、ジーニアス）。 == Can you ? == 英語では、相手に能力を直接聞くのは、失礼に当たると見なされている場合もある。 たとえば、 Can you speak Japanese? は、背景として、「あなたは日本語を話せないといけない」と思われることもある（インスパイア、ジーニアス）。このため、canを使わずに Do you speak Japanese? と聞くのが良いとされている（ジーニアス）。 一方、話し手が自分の語学の能力を「私は～できます」と言う場合は、なるべく be able to よりも canを使うほうが謙遜気味で礼儀正しいとされており、つまり I can のほうが良いとされている（ジーニアス）。I のあとに be able to を使うと、英米では能力自慢のように聞こえるらしい（ジーニアス）。 can youが無礼なのに I can が礼儀正しいのは意味不明だが、しかし覇権国家の英米人がそう使い分けているので、英語学ではそう合わせるしかない。うらやましい。所詮、語学は暗記科目であり、「理屈と膏薬はどこにでもつく」（日本のことわざ）である。 また、派生的にか、可能性のcanは疑問文では、強めの疑いや、おどろきや当惑などの意味をもつこともよくある（青チャート、インスパイア）。参考書によくある典型的な例文だが Can the rumor be true? 「そのウワサは本当だろうか？」 という疑問文では、そのような、強めの疑いや、おどろきなどの意味がある。・ さて、can は、今後も通用する能力や可能性について言うので、単に一回だけのことに「昨日は～できた」みたいに言う場合には can や could を使わない（ジーニアス、青チャート）。 1回だけ「～できた」場合には、 be able to や 「managed to不定詞」 や succeed in ～ing などを使う（青チャート、インスパイア）。 また、とくに能力などを強調するのでなければ、単に過去形だけを使って1回だけできたことを表現してもいい（ジーニアス）。 なお、否定文や疑問文の場合は could を使っても良く、つまり couldn't や wasn't（または weren't） able to でもいい（インスパイア）。 ただし、こういう細かい使い分けよりも、入試に出るのは、構文 cannot help ～ing 「～せざるを得ない」 cannot help but ＋動詞の原型 「～せざるを得ない」 cannot but ＋動詞の原型 などだろう（インスパイア、桐原ファクトブック）。 90年代、こういう二重否定的な構文が（中学範囲ではなく）高校範囲だった過去がある。 cannot ～ too ○○ 「いくら～しすぎても○○しすぎることはない」 という反語的な表現も、90年代の典型的な高校英文法の範囲であった。 そのほか、「ときに　～することがある」と好ましくない事を言う場合に can を使うことがある。ジーニアスいわく「風邪は時に重い病気につながることがある」とか、青チャートいわく「そういう事故はときどき起こりうるものだ」で can を使っている。 だが、これとは逆に思える用法もインスパイアにあり、「can はもともと備わっている能力を表す」として「be able to は一時的な能力を表す」などという用法もある。 ※ このように、助動詞まわりは、あまり規則的ではなく、またやや口語的であり、あまり日本の大学入試対策としては深入りする必要が無いだろう。上述したが cannot help ～ ing のような構文を覚えることを優先すべきである。 == 助動詞 need == 本動詞 need とは別に、助動詞 need というのがあり、 「need ＋動詞の原型」の形で使う。 助動詞 need は主にイギリス英語である。 参考書では平叙文に助動詞 need が使われることもあるが（ジーニアス）、しかし実際の英米では疑問文と否定文でのみ助動詞 need が使われるのが一般的である（青チャート、桐原ファクト）。 このような制限が助動詞 need にあるため、実のところ、あまり信用頻度は高くない、・・・というのが桐原ファクトの見解。 助動詞 need の否定形は need not または needn't であり（青チャ－ト）、つまり「 need not ＋動詞の原型」のような形になる。 また、助動詞 need に過去形は無い（青チャ、インスパ）。また、主語が三人称単数でも、助動詞 need には sはつかず、needのまま（青チャ）。 もし、過去の必要性について言いたい場合、単に、本動詞 「need to不定詞」を使えばいい（ジーニアス、青チャ、インスパイア）。 なお、本動詞 need の否定文や疑問文は、単に中学英文法と同様に I didn't need to 不定詞 や Did you need to 不定詞 ? を使えばいいだけである。 なお、完了形との組み合わせ「 need not have ＋過去分詞」だと、「～する必要はなかったのに」（＋「しかし実際は～してしまった」）という後悔や非難などの意味になる（ジーニアス、インスパイア、桐原ファクト）。 ※ インスパイア・桐原ファクトに「実際は～してしまった」の説明あり。インスパイアに「非難」の意味あり。桐原は「後悔」のみ。ジーニアスは二次熟語では表現せず。 == dare == 助動詞としては、2つの慣用文がある。 How dare say ～？　「よくも～できたものだね」 という苛立ち（いらだち）をあらわす。 I dare say ～. 「たぶん～だろう」「おそらく～だろう」 sayのあとに接続詞 that は続かない（インスパイア）。 I daresay ～ という一語でdareとsayを縮めた言い回しもある（インスパイア、ブレイクスルー）。 dare の用法は、あまり論理的ではない。ほか、助動詞 dareに過去形 dared もあるとされているが、現代ではマレ（青チャート）。 そのほか、 Bod dare not propose to her. 「ボブは彼女にプロポーズする勇気がない」 のように、否定文や疑問文で dare が使われることがある。 だが、この場合の dare は「勇気のある」の意味なので、助動詞を使わずとも courage や brave などをつかった言い表すこともできて、むしろ英米では口語には courage などの言い回しのほうが多いのが実態とのこと（エバーグリーン）。 さて、助動詞以外にも、本動詞としての dare の用法があり、上記２つの「How dare」「I dare say（または daresay）」慣用表現以外の場合では、本動詞としてdareをつかうことのほうが一般的であり（ジーニアス）、 He dares（または dared） to ～ 「彼はずうずうしくも～する（した）」 のように使うこともある（青チャ）。 == ought to == ought to は、助動詞 should と同じような意味として紹介されることもある。だが、実際には should よりも、やや意味が強い。 ought to には、「～すべきである」という義務・当然の意味や、「～するはずだ」「～にちがいない」という強い推定・見込みの意味（インスパイア、青チャ）がある。 義務の強さは、 must ＞ ought to ＞ should である（ジーニアス）。 ought は助動詞であるが、to不定詞とともに使われる。 なお、ought to の否定形は ought not to ～ である（エバー、青）。 oughtn't to ～ という短縮形の否定もある（青）。 gimo疑問文は、たとえば「私は～すべきでしょうか？」なら Ought I to 不定詞 ～? の語順になる（青、ファクト）。 つまり、 Ought 主語 to 不定詞 ～? の語順。 == had better == had better 「～したほうがいい」は、字面だけなら「推奨」の意味だが、文脈によっては「命令」や「脅し」の意味に受け取られる場合がある。 had better には「そうしないと（or）、困った事になるぞ」という含みがあると感じられる場合があるから、である（桐原ファクト、）。 とくに、主語が you の場合、命令などの意味に受け取られやすいので、注意が必要（エバー）。 このため、 I think you had better ～　のように「I think 」や maybe などをつけて、意味をやわらげる場合もよくある。 had better の否定は 「had better not 動詞の原型」である（エバ、ジーニ）。 :※ 完了形と混同してか、had better なのに had の後ろに not を置くミスが学生に多い（エバ）。 「It would be better for you to 不定詞」でも、意味をやわらげられる（青チャート、インスパ、ブレイク）ので、目上の人にはこの言い回しが良いとされる（青チャ）。 青チャートいわく、「 It might be better for you to 不定詞」や「I would suggest (that)」 などでも「～するのが良いでしょう」の意味で言い換えできる、とのこと（青チャ）。 言い換え表現のほうでは、動詞の前にtoがついてto不定詞になっているのに注意。 なお、口語では You'd better や I'd better のように、よくhad を 'd と省略する（青チャ、ブレイク）。 疑問文の語順については、インスパイアと青チャート以外、言及していない。説明の簡単のため主語を I とすると、「～したほうが良いですか？」は Had I better ～？ または Hadn't I better ～？ とのこと（インスパイア）。 いっぽう、 Han I better not ～？　「～しないほうが良いですか？」 とのこと（インスパイア）。 青チャートいわく、英語では実際によく使われるのは、 Hadn't I better ～？　「～しないほうが良いですか？」 という言い回しとのこと（青チャ）。 qu7qahv4sbox91dqnemzhkmyb35hrmb