fix incorrect Japanese sentences in intro-graphql

tutorials/graphql/intro-graphql/tutorial-site-ja/content/core-concepts.md

@@ -7,7 +7,7 @@ metaDescription: "GraphQLの中心的な概念（ドキュメント、操作、
 GraphQLは、REST APIの経験がある人向けに新しい概念を導入します。このセクションでは、クライアント/フロントエンドの観点から、GraphQLの中心的な概念について紹介します。
 
 ## GraphQLドキュメント {#graphql-document}
-GraphQL要求文字列の内容をGraphQLドキュメントと呼びます。これは、ドキュメントの一例です。
+GraphQLリクエスト文字列の内容をGraphQLドキュメントと呼びます。これは、ドキュメントの一例です。
 
 ```graphql
 {
@@ -25,7 +25,7 @@ GraphQL操作のタイプは以下の通りです。
 
 - クエリ（読み取り専用取得）
 - ミューテーション（書き込み後に取得）
-- サブスクリプション（ソースイベントに応じてデータを取得する長期間要求）
+- サブスクリプション（ソースイベントに応じてデータを取得する長期間リクエスト）
 
 GraphQLドキュメントには、これらの操作（複数のクエリ/ミューテーション/サブスクリプション）を1つまたは複数含めることができます。
 
@@ -129,7 +129,9 @@ query ($limit: Int) {
 
 #### 操作名 {#operation-name}
 
-ドキュメントが複数の操作を含む場合、サーバーは結果を同じ順序で実行する必要があることを認識し、結果を同じ順序でマッピングする必要があります。例：
+ドキュメントが複数の操作を含む場合、サーバーは結果を同じ順序で実行する必要があることを認識し、結果を同じ順序でマッピングする必要があります。
+
+例：
 
 ```graphql
 query fetchAuthor {
@@ -149,7 +151,7 @@ query fetchAuthors {
 
 これには2つの操作があります。1つは1人の作成者を取得するための操作、もう1つは複数の作成者を取得する操作です。
 
-これらは、シンプルなGraphQL要求でよく使用される最も一般的なものです。
+これらは、シンプルなGraphQLリクエストでよく使用される最も一般的なものです。
 
 ここでは、より複雑なアプリが使用する他の概念を紹介します。
 
@@ -200,7 +202,7 @@ query fetchAuthors {
 
 #### ディレクティブ {#directives}
 
-ディレクティブは、応答の値に影響を与えることなく追加機能を追加しますが、クライアントに返る応答には影響を与える場合がある識別子です。
+ディレクティブは、レスポンスの値に影響を与えることなく追加機能を追加しますが、クライアントに返るレスポンスには影響を与える場合がある識別子です。
 
 識別子 `@` の後には、オプションで名前付き引数の一覧が続きます。
 

tutorials/graphql/intro-graphql/tutorial-site-ja/content/graphql-client.md

@@ -6,7 +6,7 @@ metaDescription: "GraphQLクライアントは、queryingとcachingを改善し
 
 このセクションでは、専用のGraphQLクライアントが、どのようにqueryingとcachingを改善し、繰り返し利用可能なモジュールの構築をサポートするのかを見ていきます。
 
-GraphQL要求は、ネイティブなJavaScript Fetch APIを使用して作成できます。例えば作成者のリストを取得するためには、以下に示すようなコードを使ってqueryを実行します。
+GraphQLリクエストは、ネイティブなJavaScript Fetch APIを使用して作成できます。例えば作成者のリストを取得するためには、以下に示すようなコードを使ってqueryを実行します。
 
 ```javascript
 const limit = 5;
@@ -32,15 +32,15 @@ fetch('/graphql', {
   .then(data => console.log('data returned:', data));
 ```
 
-これを実行するための前提は、サーバーがHTTP経由でGraphQL要求を受け付けていることです。（GraphQLがプロトコルに依存しないことは覚えていますか）
+これを実行するための前提は、サーバーがHTTP経由でGraphQLリクエストを受け付けていることです。（GraphQLがプロトコルに依存しないことは覚えていますか）
 
 ## GraphQLクライアントが必要な理由 {#why-do-i-need-a-graphql-client}
 
-ここまでは旧来のFetch APIメソッドを使った要求について学んできましたが、GraphQLクライアントが必要な理由とは何でしょうか。
+ここまでは旧来のFetch APIメソッドを使ったリクエストについて学んできましたが、GraphQLクライアントが必要な理由とは何でしょうか。
 
-#### queryの構築と応答処理{#constructing-query-processing-response}
+#### queryの構築とレスポンス処理{#constructing-query-processing-response}
 
-GraphQLクライアントは、関連するヘッダーとコンテキストの情報とGraphQLドキュメントのみを使用して、完全なqueryを構築することができます。Fetch API呼び出しコードを毎回記述する代わりに、クライアントが呼び出しを処理し、パースした後に応答データやエラーを返します。
+GraphQLクライアントは、関連するヘッダーとコンテキストの情報とGraphQLドキュメントのみを使用して、完全なqueryを構築することができます。Fetch API呼び出しコードを毎回記述する代わりに、クライアントが呼び出しを処理し、パースした後にレスポンスデータやエラーを返します。
 
 #### UIステートの管理 {#managing-ui-state}
 

tutorials/graphql/intro-graphql/tutorial-site-ja/content/graphql-vs-rest.md

@@ -8,17 +8,17 @@ GraphQLは、REST APIの代替として考えられることが多いです。
 
 ## GraphQLとRESTの比較例 {#example}
 
-ユーザーのプロファイルとアドレスを取得するAPIがあるとします。典型的なRESTのシナリオでは、要求と応答は次のようになります。
+ユーザーのプロファイルと住所を取得するAPIがあるとします。典型的なRESTのシナリオでは、リクエストとレスポンスは次のようになります。
 
 ![ GraphQL APIの例 ](https://graphql-engine-cdn.hasura.io/learn-hasura/assets/graphql-react/rest-api.png)
 
-REST APIの核心はリソースをあります。リソースは、URLと要求タイプ（GET、POSTなど）で識別されます
+REST APIの核心はリソースにあります。リソースは、URLとリクエストメソッド（GET、POSTなど）で識別されます
 
-APIサーバーがGraphQLサーバーであれば、APIの呼び出しは次のようになります。
+一方でAPIサーバーがGraphQLサーバーであれば、APIの呼び出しは次のようになります。
 
 ![ GraphQL APIの例 ](https://graphql-engine-cdn.hasura.io/learn-hasura/assets/graphql-react/graphql-api.gif)
 
-クライアントが送信した「クエリ」に応じて、応答JSONが異なることが分かります。
+クライアントが送信した「クエリ」に応じて、JSONレスポンスが異なることが分かります。
 
 ```
 Request1:         |  Response1:
@@ -46,7 +46,7 @@ query {           |   {
 APIの呼び出しに対する考え方を変えていきましょう。データを取得するために複数のURLそれぞれに対してAPI呼び出しを実行するのではなく、「単一のURLエンドポイント」にアドホックなクエリを行えば、クエリに応じたデータを返すことができます。
 - リソースを「GET」する代わりに、必要なデータを記述したクエリを「POST」します。
 - APIが返すデータを「グラフ」と捉えれば、「関連する」データを1回で取得するクエリを作ることができます。上記の例では、API呼び出しを2つ使うのではなく、1つのAPIコールでユーザーとアドレス（ネストされたJSONオブジェクトとして）を取得しています。
-- POST要求のデータとして送信する「クエリ」には、構造と構文があります。この「言語」をGraphQLと呼びます。
+- POSTリクエストのデータとして送信する「クエリ」には、構造と構文があります。この「言語」をGraphQLと呼びます。
 
 上記の例で分かるように、すっきりして読みやすいのがGraphQLクエリの特徴です。これは、このクエリが最終的に目指す「形式」がJSONデータだからです。これがGraphQLを扱うのが楽しい理由の1つです。
 
@@ -59,7 +59,7 @@ APIの呼び出しに対する考え方を変えていきましょう。デー
 
 RESTとGraphQLの類似コードを以下に示します。
 
-| 要求 | REST | GraphQL |
+| リクエスト | REST | GraphQL |
 | :-- | :-- | :-- |
 | データオブジェクトの取得 | GET | query |
 | データの挿入 | POST | mutation |
@@ -74,17 +74,17 @@ REST APIでは、スキーマや型付けシステムの概念はありません
 
 ### HTTPステータスコード {#http-status-codes}
 
-GraphQL要求、成功、またはエラーはすべて、200を返す必要があります。これは、それぞれのステータスコードが特定のタイプの応答を指すREST APIとの明確な違いです。
+全てのGraphQLリクエストにおいて、成功もエラーも共に200を返す必要があります。これは、それぞれのステータスコードが特定のタイプのレスポンスを指すREST APIとの明確な違いです。
 
 | ステータスコード | REST | GraphQL |
 | :-- | :-- | :-- |
 | 200 | Ok | Ok |
-| 400 | 不正な要求 | - |
+| 400 | 不正なリクエスト | - |
 | 401 | 未承認 | - |
 
-REST APIでは、エラーは200であり、エラーを処理クライアントはさまざまなコードの可能性を考慮する必要があります。
+REST APIでは、エラーは200以外のステータスコードであり、処理クライアントはさまざまなエラーの可能性を考慮する必要があります。
 
-GraphQLでは、有効な応答（データとエラーの両方）は必ず200です。エラーは、特殊な `errors` オブジェクトのレスポンスボディとして処理され、クライアント側ツールが処理するのに役立ちます。
+GraphQLでは、有効なレスポンス（データとエラーの両方）は必ず200です。エラーは、特殊な `errors` オブジェクトのレスポンスボディとして処理され、クライアント側ツールが処理するのに役立ちます。
 
 #### モニタリング {#monitoring}
 

tutorials/graphql/intro-graphql/tutorial-site-ja/content/what-is-graphql.md

@@ -18,18 +18,18 @@ GraphQLの理解を深める前に、HTTPクライアントで実際にGraphQL
 
 ### クライアントサーバーにおけるGraphQLの処理フロー：{#graphql-client-server-flow}
 
-1. まず初めに、GraphQLクエリは、*望んでいる*JSONと似たフォーマットをしていますが、JSONではありません。そのため、「POST」要求を作成してGraphQLクエリをサーバー送信すると、クライアントからは「文字列」になって送信されます。
+1. まず初めに、GraphQLクエリは、*望んでいる*JSONと似たフォーマットをしていますが、JSONではありません。そのため、「POST」リクエストを作成してGraphQLクエリをサーバーへ送信されますが、クライアントからは「文字列」になって送信されます。
 2. サーバーはJSONオブジェクトを取得して、クエリの文字列を抽出します。GraphQLの構文とグラフのデータモデル（GraphQLスキーマ）に従って、サーバーはGraphQLクエリの処理と検証を実施します。
-3. その後は、一般的なAPIサーバーと同様に、GraphQL APIサーバーはデータベースや他のサービスを呼び出して、クライアントが要求したデータを取得します。
+3. その後は、一般的なAPIサーバーと同様に、GraphQL APIサーバーはデータベースや他のサービスを呼び出して、クライアントがリクエストしたデータを取得します。
 4. 次に、サーバーはデータを取得し、JSONオブジェクトにしてからクライアントに返します。
 
 ### GraphQLクライアントの設定の例：{#example-of-graphql-client-setup}
 
-実際のところ、日々の作業でHTTPの要求と応答の基礎的な部分を心配する必要はありません。
+実際のところ、日々の作業でHTTPのリクエストとレスポンスの基礎的な部分を心配する必要はありません。
 
-REST APIとHTTPクライアントを使えばAPIを呼び出して、応答処理のための定型文が削減できます。それと同様に、GraphQLクライアントを選択すれば、GraphQLクエリの作成、送信、応答処理がより簡単になります。
+REST APIとHTTPクライアントを使えばAPIを呼び出して、処理のための定型文が削減できます。それと同様に、GraphQLクライアントを選択すれば、GraphQLクエリの作成、送信、応答処理がより簡単になります。
 
-実際、GraphQLクエリを送信して、その応答を受理する仕組みは標準的なものになっています。これにより、クライアントでのGraphQLの操作は非常に簡略化されています。
+実際、GraphQLクエリを送信して、そのレスポンスを受け取る仕組みは標準的なものになっています。これにより、クライアントでのGraphQLの操作は非常に簡略化されています。
 
 典型的なGraphQLクライアントのセットアップと、クエリの作成コードは以下の通りです。