[表記揺れ?] 全体的にこのPlotlyのチートシートでは名詞の plots は「グラフ」と訳しているようです （Matplotlibみたいに同じplotsでも実は別のオブジェクトを指しているなどだと用語を使い分けた方が良いかもしれませんが、Plotlyの構造詳しくないのでちょっとよくわかりません...

立方数のための新しいtraceを追加する

とかでしょうか

最高気温のための新しいtraceを追加する

とかでしょうか

方

方

好みかもしれませんが、ここは「集まり」などの方が自然かなと思いました。

[日本語] (1) 「ここには...ページです」だと主語（？）と動詞が対応していない感じがするので、「これは...ページです」の方が自然だと思います。

(2) 「示すリファレンスページ」より「確認できるリファレンスページ」などの方が日本語としては自然かなと思います。

代案:

これは、Plotlyで作成できる全ての種類のグラフを確認できるリファレンスページです。

原文:

The labels dictionary lets you specify which aspects of the plot will have custom labels.

原文だと labels がコード表記なので、引数または変数のlabelsを指していそうです。

代案:

辞書labelsを使うと、グラフのどの要素にカスタムラベルを設定するか指定できます。

などでしょうか。

の が連続してちょっと読みにくいので

その他可視化のためのフォーマットを指定する引数を受け取ることもできます。

などはどうでしょうか

(1) <br /> 「プロットが表示されたブラウザの」で区切って呼んじゃってちょっとわかりにくかったです。

(2) <br /> plots がひとつ前の文では「グラフ」、この文では「プロット」と書かれて別のものを指してるのか、表記揺れなのか悩みました（原文はどちらもplots）。意図的に使いわけているのでなければ統一した方が良いと思います。

代案:

コードに興味があれば、プロットが表示されたときにブラウザのインスペクターツールを開いてください。

[表記揺れ] 17章では 対話的 と書いていたような

本文（15章など）で、axが表している plot のことを プロット と書いているので、ここは プロット の方が良いと思います。 たとえば、plt.subplots()で作成したプロット（ax）の中に複数の折れ線グラフを含めることもできるので、axのことを「グラフ」と呼ぶとちょっとややこしく感じます。

例: ひとつのプロット（ax）に複数の折れ線グラフがあるケース https://matplotlib.org/stable/gallery/lines_bars_and_markers/errorbar_limits_simple.html#sphx-glr-gallery-lines-bars-and-markers-errorbar-limits-simple-py

他の箇所も同様。

プロット

原文が separate plot で、ここでのプロットはAxesオブジェクトのことなので

別々のプロット

の方が適切だと思います。

原文:

You can include as many individual graphs in one figure as you want.

individual の意味が抜けています。このindividualは「1つのプロット（Axesオブジェクト）内に複数のグラフを描く」のではなく、「Axesオブジェクト自体を分けて、別々にグラフを描く」という意味が強調されていると思うので、

1つの図に、独立したグラフをいくつでも含めることができます。

の方が適切だと思います。

プロット

[技術的な正確性]

ここは1つのFigureオブジェクトに複数のAxesオブジェクトを作る例なので、

1つの図に複数のプロット

が正しい表現かと思います。

描画

描画

本文では datetime object を 「datetime オブジェクト」と訳しています（コード表記の有無であえて訳を使い分けてる？）

日付

本文や Working with dates and times　では 日付 と訳されているのですが、一部の箇所で 日 になっています。日本語としては 日付 の方が自然だと思います。

日付

代案:

また、facecolor で塗りつぶしに使う色を、オプション引数のalpha で色の透明度を受け取ります。

元の原稿だと、文前半と末尾の表現が揃っておらず違和感があります。

の　が続くので、シンプルに データセット間　の方が良いかと思います

の　が続くので、シンプルに データセット間　の方が良いかと思います

描画

描画

名詞の プロット とややこしいので

typo 「の」

原文:

When you make multiple plots, you can emphasize relationships in the data

原文の plots を プロット と訳しているのですが、この表現だとAxisオブジェクトを複数作っているように受け取れてややこしいので、ここは グラフ などの表現の方が技術的には正確だと思います。

「複数のプロット」と言われると 下記のような複数のAxesオブジェクトを作るケースを想像します。

fig, axes = plt.subplots(2)

サンプルコードを見たところ、ここはAxesオブジェクト自体を複数作るのではなく「Axesオブジェクトを1つ作って、その中に複数のグラフを含める」パターンなので、plots = グラフ の方が適切かと。

代案:

1つの図にいくつもデータを描画できます。

動詞の plot を「プロット」と訳すと、名詞の plot （主にAxesオブジェクト）とややこしいので...

原文は Multiple plots なのですが、サンプルコードを見ると「1つのFigureオブジェクトに複数のAxesオブジェクト（プロット）がある」のではなく「1つのAxesオブジェクト（プロット）に複数のグラフがある」という内容になっているので、ここは

複数のグラフ

の方が良いと思いました。

全体的に原文が

• Figureオブジェクト（図/描画オブジェクト）
• Axesオブジェクト（プロット/サブプロット）
• Axesオブジェクト内に描画されるデータ（グラフ？）

をあまり区別せずにひとくくりで plot と呼んでいるようで悩ましいのですが、実際に指しているものが何かを意識して用語を使い分けた方が混乱しないと思います。

別コメントで「変数ax を指している plot の訳は プロット の方が良い」的なことを書いているのですが、ここの原文が指している plot は 図全体のことを指しているので、ここは「グラフ」のまま、あるいは 「図」で良いと思います。

別コメントで「変数ax を指している plot の訳は プロット の方が良い」的なことを書いているのですが、ここの原文が指している plot は fig の方なので、ここは「グラフ」のまま、あるいは 「図」で良いと思います。

好みかもしれませんが、やや違和感ありました （カスタマイズ（名詞）と完全に削除できます（動詞）が並列になってるから？

以下はどうでしょうか

軸をカスタマイズしたり、完全に削除したりすることも可能です。

原文:

You can plot as much data as you want on one plot. H

前半の plot が変数 ax のことを指していると思うので

1つのプロットに必要なだけ大量のデータを描画できます。

とかですかね。

やや冗長でわかりにくいので

各点の色を決めるための値

はどうでしょうか

「軸のスケールを追加」が日本語として変なので

タイトル、ラベルの追加と、軸のスケーリング

あるいは

タイトル、ラベルの追加と、軸のスケール変更

（原文が Adding titles and labels, and scaling axes なので、 adding と scaling が並列の関係になります）

[技術的な正確性]

This convention is used even when there's only one plot in the figure.

現在の原稿だとfigureもplotも「図」になっているのですが、

• figure は描画オブジェクト（変数fig）
• plot はプロット（変数ax）

のことで、明確にオブジェクトの種類が違うので、用語を分けた方が良いと思います。

代案:

この慣例は、図の中にプロットが1つしかない場合でも使われます。

（ここでの convention が「axは図（描画オブジェクトfig）の中のプロットを表す」ということであれば、慣例というよりライブラリのルールなので、 慣例　 より 決まり / ルール の方がしっくりくる気もしますが...

プロット（理由は別コメントと同様）

[日本語の文法]

代案:

簡単な可視化を始める上で役に立ちます。

ここはシンプルに 子孫 だけでよいのでは。 （次の文も 子 だけなので）

原文だと31353677はコード表記されています。

nits: <br /> ちょっと一部に読点が多いように感じるので

大きく異なる点は、出力がそれほど長くないので、フォーマットされた結果の文字列をファイルに書き込まずに出力しているところです❶。

はどうでしょうか（好みかも

typo？　が

typo 「カスタマイズ」

「グラフのほとんどの要素を更新する」のか「グラフのほとんどの要素を、更新するメソッド経由で」なのかわかりづらかったです。

「更新するメソッド」とあるのですが、これは update_...メソッド群のことだと思うので、シンプルに「更新メソッド」と表現した方がイメージが伝わりやすいかなと思いました。

代案:

一旦グラフを作成したら、グラフのほとんどの要素は更新メソッド経由でカスタマイスが可能です。

typo？「を」では。 title_font_sizeのように 「aspects of a chart element」（titleとfontとsize）がunderscoresで繋がれているので。

全体を修正するなら、

Plotlyでは、グラフの要素の特徴をアンダースコアで繋げるという慣例があります。

などでしょうか（aspectsをどう訳すか悩むけど...

代案:

タイトルを追加して各軸にラベルを付けたら、グラフへのスタイル設定をはじめます。

元の原稿だと「タイトルの追加」の後に「ラベルをつけることでグラフにスタイル設定をする」という作業があるように読めるのですが、原文だと by adding a title and labels for each axis で「タイトルの追加」と「ラベルの付与」がセットなので、代案のように読点の位置を変えた方がイメージが伝わりやすいと思います。

直訳すればそうなのですが、日本語としては少し違和感ありました。

たった2行のコードを書くだけで、最初の可視化を行えます。

あるいは

最初の可視化は、たった2行のコードを書くだけです。

などでしょうか...

最初のグラフに

とかですかね。「初期状態のグラフ」という言い方がちょっと違和感ありました。

代案

もう調査フェーズではなく

nits <br /> 意訳の範囲としてOKな気もしますが、 the data we want. なのでどちらかというと 欲しいデータ かなと思いました

別コメントでも書いたように、結果がset型っぽく受け取れます。 もし実際にset型でないのであれば、

結果が完全な集合か確認する

あるいはシンプルに

完全な結果が得られたか確認する

などの方が日本語としては自然に感じました

あんまりわかってないのですが、「API呼び出しを作成する」という言い回しは日本語でよく使われる表現なのでしょうか（API呼び出しを行うようなオブジェクトを生成してるように聞こえる）

あまりない表現であれば、単純に「API呼び出しを行います」「API呼び出しをします」でも良いのでは、と思いました。

「比較して可視化」だと「比較した後に可視化する」ように読めて違和感ありました。

原文は「relative popularity」なので「相対的な人気を可視化しましょう」か、あるいはやや意訳して「人気を可視化して比較しましょう」の方がイメージが近いかなと思います。

nits

一文が長いので読点が欲しいです

API呼び出しから返される各リポジトリについて、選択した情報を出力するループを書きましょう。

• 文が長いので、読点を入れた方が良い
• 「public-apis」がプログラマーが と が が続くので、「public-apisには...含まれている」と受動態にした方が読みやすいかなと思います
• mightがあるので、「興味のある」ではなく「興味を持つかもしれない」「興味を持ちそうな」では。

代案:

また説明文から、「public-apis」にはプログラマーが興味を持ちそうなフリーのAPIのリストが含まれていることがわかります。

typo？ 最近更新されて

nits ひらがなが続くので、読点があった方が読みやすいかなと思います。

代案:

repo_dict にあるキーのうち、いくつかの値を取り出してみましょう。

「様子がわかるでしょう」という言い回しがちょっと違和感ありました

参考: get a sense of = 〜を感じ取れる、何となく分かる <br /> https://eow.alc.co.jp/search?q=get+a+sense+of

代案:

これらのキーを見渡せば、プロジェクトに関してどんな種類の情報を抽出できるのか把握できるでしょう

あるいは

これらのキーを見渡せば、プロジェクトに関してどんな種類の情報を抽出できるのか何となくわかるでしょう

などはどうでしょうか

追加のデータページ

でしょうか。「データの追加ページ」だと、データを追加するページっぽく感じました。

[nits] <br /> ちょっと一文が長いので読点があった方が良いかと。

各リポジトリの情報をより詳しく見るために、 repo_dicts の最初の要素を取り出して repo_dict に代入します❸。

[nits] <br /> 日本語としては ここでは、 のようなワンクッションおいた表現があった方が自然な流れで読めると思いました。

（原文には「ここ」という表現はないですが、「we print ...」の we が示す「私たちはこうするよ」感を「ここではこうするよ」と意訳する感じ

代案:

ここでは、この値を直接出力するのではなく、逆の値を出力します。

「セット」とカタカナで書かれるとset型のデータっぽく感じるのですが、実際にそうなっているのでしょうか（未確認）。 もしset型でなければ、 結果の集合 と言った表現の方が自然に感じました。

typo？

API呼び出しを作成して、レスポンスを確認する

あるいは

APIを呼び出して、レスポンスを確認する

でしょうか（他のコードにも同様の記述あり

今回の差分の範囲外ですが、ちょっと文意がわかりにくかったです。

This is a good way to make sure we received the information we expected, and to start examining the information we're interested in:

なので、

これは期待通りに情報を取得できたか確認して、関心のある情報について調べ始める上で良い方法です。

などでしょうか（これもちょっと直訳感があるけど...

「ヘッダー定義で使用する」と読めちゃうので、語順を入れ替えた方が誤解が生じないかと思います。

代案:

使用するAPIのバージョンをAPI呼び出しのヘッダー定義で明確に指定し、結果をJSONフォーマットで返します❷

「よう」

(1) <br /> APIへのレスポンス性能

「ユーザに対するAPIのレスポンス性能」あるいは「ユーザへのAPIレスポンス性能」では。原稿の表現だと、APIに向かってレスポンスを返しているようです。

(2) <br /> [nits] ここの文は、前文の「GitHubのプロセスが途中で止まっている」ことを補足するための文なので、語順を入れ換えた方が「プロセスが途中で止まってるのは、実行時間を制限してるから」という流れがわかりやすいかなと思いました（これは好みかも

代案:

GitHubは全てのユーザーに対してAPIのレスポンス性能を維持するために、各クエリの実行時間を制限しています。

代案:

"incomplete_results" の値が true になっており、GitHubがクエリーを完全には処理しなかったことをがわかります❷

でしょうか。 「全プロセスが完了していない」だと「全然処理できなかった（進捗率0%）」のか「全部は処理できなかった（一部はできた可能性がある）」のか判断しづらく感じました。

やったね🎉🎉🎉

nits. 「その代わりに」という書き出しだと、「一般的なタイトルを使用した引き換えに何かする」みたいな展開を予想したので、

代わりに、

の方が自然かなと思いました（好みかも

typo

この値を取り出して変数titleに代入します

シンプルに 概要 でよいかと （「概要」という言葉自体に情報という意味合いが含まれると思うので...

他の箇所だと、図を参照する時は太字にしているようです。 （他、同様の箇所あり）

「データパターンの確認に連続する色が役に立つデータセットで」がわかりにくかったです。

語順を入れ替えて

連続する色がデータパターンの確認に役立つようなデータセットで

あるいは、やや言葉を補って

連続的に変化する色を使うことでデータパターンがわかりやすくなるようなデータセットで

はどうでしょうか。

もわかります

nits. （だいぶ好みによりけりな気もしますが）ここは「確認します」より「わかります」の方が簡潔でしっくりくるなと感じました

原文が regions of the world なので 「世界の」のtypo？

(1) 「長い」が修飾しているものがわかりにくく（関数呼び出しが長いのか、引数名が長いのか、リストが長いのか）、ちょっと違和感あります。

(2) 文後半で「...ことで...ことが一般的です」と「こと」が繰り返されてやや冗長に感じます。

まとめると、以下はどうでしょうか。

関数呼び出しの引数リストが長くなり、このように複数行にまたがる場合は、行末にカンマを付けて次の行に他の引数を追加しやすくするのが一般的です。

色をカスタマイズできます

nits. 「..では...は」が連続するので、読点を入れた方が読みやすいかと思います（好みかも

デフォルトでは、カラースケールは地図の右側にcolorというラベルで表示されます。

(1) pick out は 取り出す という意味もありますが、ここは 見分ける / 明らかにする のニュアンスを採用した方が日本語としては自然に感じます。

（「取り出す」だと何か抽出してるっぽいので

https://ejje.weblio.jp/content/pick+out

(2) 「より良い」というより「（さっきと比べて）良くなってきている」みたいな表現の方が自然かと

(3) nits. 「 the most significant earthquakes」なので、「最も大きな」というより「最も重要な」では（どのみちマグニチュードが大きな地震を「重要」と定義してるっぽいので、あまり違わないですが...）

まとめると、以下はどうでしょうか

この地図は良くなってきてはいますが、最も重要な地震がどの点なのか見分けるのは、まだ難しいです。

あるいは

この地図は良くなってきてはいますが、最も重要な地震がどの点なのか見分けるのは、未だ困難です。

(1)

一般的に近くプレートの境界線の近く

「近く」が1個余分なようです。

(2) 1文が長いので分けた方が良さそう。

地震は一般的にプレートの境界線付近で発生します。この地図に含まれる長い期間の地震活動によって、これらの境界の正確な位置がわかります。

よう

併せて -> 合わせて　?

あるいは「あわせて」という言葉を使わずに

マグニチュードが大きい地震ほどより大きな点で地図上に表示されます

などはどうでしょうか。

24時間内

あるいは

24時間以内

ここは（実践編だけで1冊になるので章番号が変わって）4章になるのでは。

図番号が違うようです（図5-7）

差分の範囲外ですが

24時間以内に

の方が自然な表現かなと思います。

原文が

convert the string representation of the file to a Python object

で、「convert A to B」（AをBに変換する）なので、

ファイルの文字列表現をPythonオブジェクトに変換します。

の方が適切かと。

日々の最高気温を測定した日付 が何なのかがわかりにくかったです。 （訳だけだと「期間中の最高気温を叩き出した日を抽出する」ように受け取れるけど、コードでやっているのは「毎日の最高気温と、日付を抽出する」という処理）

extracting dates for the daily high temperature readings の訳が難しいのですが、

毎日の最高気温の記録から日付を抽出し、これらの日付を X軸 に使うことで、グラフを改善できます。

はどうでしょうか

[表記揺れ]

weather data

の訳が天気データ / 気象データ で表記揺れしています

(1) 「each line」が「各行」と訳されているのですが、ヘッダーが示しているものなので「各列」では。

(2) 日本語としては、

見ての通り、header_row は天候に関連した意味のあるヘッダーを含んでおり、データの各列が何の情報を持つか示しています。

といった語順の方がわかりやすいかなと思いました。

あと「what information each line of data holds」は「各行がどのようなデータを持つか」というより「データの各行が何の情報を持つか」かと。 （データ/情報/ヘッダーとdata/information/headerが微妙に対応していない訳になっていて気になった

「最初の行から次の行」 -> 1行目と2行目を返すことかな？と一瞬思いました。

next()の挙動を考えると、「実行するたびに先頭から順に"次の行"を返す」ということを言いたいのだと思うので

reader オブジェクトを渡すと、next() 関数はファイルの先頭から順に次の行を返します。

とかの方がイメージに近いかなぁと思います。

「メソッドをチェーンし」という表現が初心者に通じるかな？と引っ掛かりました（メソッドチェーンと言うから変ではないんだろうけど）

シンプルに

ファイルを読み込んでsplitlines()メソッドを繋げ、

などはどうでしょうか

[読みやすさ] ちょっと一文が長くて「フォルダー」が2回登場するので、読点入れた方が文意を理解しやすいかなと思います。

この章のプログラムを保存するフォルダーの中に、weather_dataという名前のフォルダーを作成します。

あるいは、ここから読者にやってほしいことの指示内容なので、文末を変えて

この章のプログラムを保存するフォルダーの中に、weather_dataという名前のフォルダーを作成してください。

など。

[確認] 第16章では？と思ったけど、実践編だけで1冊になっているから5章でOKということでしょうか（一応念のため

figと.の間に余計な半角スペースが入っているようです

px.bar()関数の呼び出し時には、オプションの引数titleとlabelsを含めます。

とかでしょうか。「含まれます」だと、自分で指定してないのに勝手に含まれる感じがするので...

[日本語の自然さ] を　が2回登場してやや読みづらいので

辞書のキーにはカスタマイズしたいラベルの要素を指定し

はどうでしょうか。

the available space なので

利用可能なスペース

とかどうでしょうか（サイズが1つの文の中で何度も登場して違和感があって原文を確認したら、片方は size ではなく space だったので）

[日本語の文法] 「データを...表現されている」で、主語と述語が食い違っているようです。 「グラフ」を主語にする場合は

データを求める形で表現していることが確認できます

「データ」を主語にする場合は

データが求める形で表現されていることが確認できます

ただ「データを求める」「データが求める」で区切れてしまってやや読みにくいので

期待する形でデータが表現されていることがわかります。

などの方が誤解がないかも。

「使い方は...指定します」で主語と述語が対応していないようなので、

この関数の最も簡単な使い方は、x座標とのセットとy座標のセットを指定するだけです。

でしょうか。

「可視化を生成する」って日本語ではあまり聞かないので、シンプルに「可視化ができる」の方が自然に感じました（好みかも

Plotly Expressを使ってたった数行のコードで可視化ができます。

などでしょうか。

typo。「と」

「を」？

[nits][表記揺れ] 差分の範囲外ですが、 - 図4-9では 5,000 points を 5,000ステップ - 図4-11では 50,000 points を 50,000点

と訳しています

「単純な」の方がニュアンス近いかと。

nits. ちょっと日本語としては大仰な感じがするので、簡潔に

そのデータを使ってMatplotlibで魅力的な可視化を行います。

とかですかね。

nits

差分の範囲外ですが、「やってみよう」の指示なので、ここは

カラーマップを適用してください。

と呼びかける形の方が自然かと思いました

ここも、既存の他の箇所の表記に合わせると、 「引数color」になります

以降、同様の指摘は省略します

(1) 効果的なデータ可視化を生成することは という表現が直訳っぽくて日本語としては不自然に感じるので

効果的なデータ可視化を行うことは

あるいは、ちょっと意訳になりますが

効果的なデータ可視化は、

などの方が自然かも。

(2) また、多分、ここの文は「効果的なデータ可視化はかっこいいグラフを作ることじゃないよ！」ということを言いたいのだと思うので、見た目をよくする も 見栄えのよい とかの方がより伝わるかなと思います。

(3) just -> 「単に」のニュアンスが抜けてるみたい

まとめると、

効果的なデータ可視化とは、単に情報の見栄えを良くすることだけではありません。

とかでしょうか。

既存の他の箇所の表記に合わせると、 「引数color」になります

ちょっと直訳っぽいので、

これらを使うことで、多くのカスタマイズをしなくても、魅力的な可視化ができるようになります。

とか？

ここも差分の範囲外なのですが、

use a number of methods to customize your plots after generating them.

なので、

また、プロットの生成後は多くのメソッドを使ってカスタマイズが可能です。

の方が日本語としては自然かなと思いました。

今回の差分の範囲ではないのですが、

You can specify a number of arguments when calling plot()

なので、

plot() の呼び出し時には、たくさんの引数を指定できます。

の方が技術的には正確かと思います。 （元の訳だと、「plot()を呼び出すために（目的）、引数を使う」ように受け取れて、ちょっと違和感あった...

(1)

see what works best in the resulting graph.

「グラフが効果的になるように」というより 「グラフの中で、（どのくらいの文字サイズが）ベストか」みたいな意味かなと思いました

(2) It is worth は ...する価値がある　という意味なので、 It's often worth は しばしば価値がある かなぁ。

https://ejje.weblio.jp/content/it+is+worth

上記を踏まえると、

代案:

これらの値を調整して、結果のグラフの中で最も効果的なものを確認することは、多くの場合価値があります。

とかですかね...（これも直訳っぽい感じはするけど...

(1) plot -> プロット

ここの plot はメソッドのplot()のことではなく、plt.subplots()で生成されるプロット（つまり変数ax）のことだと思うので、他の文章同様カタカナで プロット　の方が適切だと思います。

(2) plotを一度生成すると、...そのグラフを変更するための多数のメソッドが存在します。

という表現が直訳っぽくて、日本語としては意味がわかりにくかったです。 多分ここで言いたいのは「plt.subplots()でプロットaxを作ったら、axのメソッドを使って色々カスタマイズできるぜ！」ということだと思うので、「修正するためのメソッドがたくさん存在します」というよりは「たくさんのメソッドを使って修正できます」といった表現の方が自然かなと思います。

代案1:

一旦プロットを生成したら、描画前にたくさんのメソッドを使って修正できます。

modify から意訳気味になるけど、「調整」「カスタマイズ」とかの方が日本語としては自然な気はする（好みかも

代案2:

一旦プロットを生成したら、描画前にたくさんのメソッドを使って調整できます。

(1) most of the time は「最もよく」というより、「たいていの場合」「ほとんどの場合」という意味みたい？ https://ejje.weblio.jp/content/most+of+the+time

(2) 単一のグラフ -> 単一のプロット （a single plot）

ここの a single plot は ax に格納されているもののことを指している & 他の箇所では「プロット」と表記しているので、 単一のプロット の方が良いと思います （あえて「グラフ」という違う言葉を使うと、描画オブジェクト（fig）のことか？とかプロット内の折れ線グラフのことか？とか、別のオブジェクトを想像しちゃう

上記を踏まえると、

これは、単一のプロットを定義してカスタマイズするときに、ほとんどの場合使用する変数です。

などでしょうか。

nits 「データ可視化とは...ことです」の方が日本語としては自然に感じます（ただ、これは好みの範囲かも

ワンタイムパスワードでログイン後にPublicでコメント