はじめに

Pythonを学び始めてしばらくすると、GitHubのプルリクエストや課題提出で 「コードレビュー」という壁にぶつかる人が多いです。 コメントで指摘をもらっても、 「なぜそこを直す必要があるの？」「動いているのにダメなの？」と、 モヤっとした気持ちになること、ありませんか？

実はコードレビューは、バグ探しやダメ出しの場ではありません。 特にPythonのような動的型付け言語では、 設計の妥当性・読みやすさ・将来の変更しやすさを 人の目で確認することがとても重要です。

この「何を、どんな視点で見られているか」を知らないままレビューを受けると、 毎回指摘に振り回されてしまいます。 逆に、レビューで見られるポイントを事前に理解していれば、 指摘は「成長のヒント」に変わります。

この記事では、Python初心者の方に向けて、 コードレビューで実際によくチェックされるポイントを 体系的に整理して解説します。 スタイルや命名といった基本から、設計・パフォーマンス・セキュリティまで、 「なぜそこを見られるのか？」が分かる構成にしています。

レビューが怖いものではなく、 「自分のコードをレベルアップさせる仕組み」だと感じられるようになること。 それがこの記事のゴールです。 一緒に、レビューされる側としても、いずれレビューできる側としても、 一歩ずつ理解を深めていきましょう 🙂

1. コードレビューとは何か？なぜPythonで重要なのか

コードレビューと聞くと、 「バグを見つける作業」「間違い探し」 というイメージを持っている人は少なくありません。 でも実際のレビューで一番見られているのは、 コードが“長く安全に使えるかどうか”です。

特にPythonは動的型付け言語です。 コンパイル時に型チェックが行われないため、 コードは実行できてしまうけれど、 後からバグを生みやすい構造になっているケースも多いです。

そのためコードレビューは、 デプロイ前に行う最後の品質チェックとして、 次のような点を重点的に確認します。

• 他人が読んでも意図がすぐに分かるか
• 変更や機能追加に耐えられる設計になっているか
• パフォーマンスやセキュリティ面で危険な書き方をしていないか
• 将来のバグの温床になりそうな構造になっていないか

ここで重要なのは、 「動くかどうか」だけでは合格にならない という点です。 チーム開発では、数か月後・数年後に 別の誰かがそのコードを触る可能性があります。

だからこそレビューでは、 「今の自分」ではなく 未来の誰かが読んでも理解できるか という視点が強く求められます。

この考え方は、いわゆる 「綺麗なコード」の発想と直結しています。 レビューで何度も指摘される人は、 スキル不足というより、 評価される視点をまだ知らないだけ というケースがほとんどです。

コード品質そのものの考え方については、 次の記事でより詳しく解説しています。

【実務で評価される】読みやすく変更しやすい「綺麗なコード」の書き方｜悪い例と改善ポイント

はじめに プログラミングを学んでいると、「とりあえず動けばOK！」という気持ちになりがちですよね。もちろんコードが動くこと自体は大事なのですが、実際の仕事では「チームの人が読みやすく、変更しやすいコード」を書けるかどうかが大きな評価ポイント...

python.cbagames.jp

2025.09.19

次の章では、 初心者の方でもイメージしやすいように、 コードレビューがどんな流れで進むのか を順番に見ていきます。

2. コードレビューの基本的な流れ（初心者向け）

コードレビューは、いきなり誰かがコードを読み始めるわけではありません。 実務では、いくつかの段階を踏んで進められるのが一般的です。 この流れを知っておくだけでも、 レビューで指摘されるポイントがかなり予測できるようになります。

① 事前セルフチェック（コードを書く側）

レビューは「提出してからが本番」ではありません。 実は、レビューの質は提出前にほぼ決まります。

• フォーマッター（Blackなど）でコードを整形しているか
• Linterで明らかな警告が出ていないか
• テストがローカル環境で通っているか

ここができていないと、 本来見るべき設計やロジック以前に 「スタイルの指摘」ばかりになってしまいます。

② 自動ツールによるチェック（CI）

最近の開発では、GitHub Actionsなどを使った 自動チェック（CI）がほぼ必ず入ります。

自動ツールは、次のような 機械的に判断できる部分を担当します。

• PEP8に違反していないか
• 未使用の変数や不要なimportがないか
• テストが失敗していないか

CIが落ちている状態でレビューを依頼すると、 「まずCIを直してください」で終わってしまうことも珍しくありません。

③ 人によるレビュー（本質的なチェック）

ここからが、いわゆる本当のコードレビューです。

レビュアーは、次のような ツールでは判断できない部分を見ています。

• 処理の意図がコードから読み取れるか
• 設計として無理がないか
• バグを生みやすい構造になっていないか
• 将来の変更に耐えられるか

ここでの指摘は、 「今すぐ直さないと壊れる」ものから 「今は動くけど後で困る」ものまで幅があります。

④ フィードバック対応・修正

レビューコメントを受けたら、 ただ直すだけでなく、 なぜその修正が必要なのか を意識して対応することが大切です。

この積み重ねが、 次に書くコードの質を確実に上げてくれます。

⑤ 承認・マージ

必要な修正がすべて終わり、 動作・品質ともに問題がなければ 「LGTM（Looks Good To Me）」が付き、マージされます。

次の章からは、 このレビュー工程の中で 実際にどんなポイントが見られているのか を、チェックリスト形式で詳しく見ていきます。

3. コードレビューで見られるポイント【チェックリスト形式】

ここからは、レビューで実際によくチェックされるポイントを、 初心者の方でも意識しやすいように チェックリスト形式で整理していきます。

すべてを完璧に満たす必要はありません。 ただし「どこを見られているか」を知っているだけで、 レビューの通り方は大きく変わります。

3-1. スタイル・命名規則（最初に見られる）

コードレビューでまず確認されるのが、 スタイルと命名です。 ここが整っていないと、 中身を見る前に「読みにくい」という印象を与えてしまいます。

PEP8に沿った書き方になっているか

Pythonでは、PEP8という公式のコーディング規約があります。 インデントは4スペース、 無駄な空行が多すぎないか、 行の長さが極端に長くなっていないか、などが見られます。

最近はBlackなどのフォーマッターを使う前提のチームも多いため、 手動で整えるより自動化する意識が大切です。

変数名・関数名から処理内容が想像できるか

レビューでよくある指摘が、 「この変数、何を表していますか？」というものです。

data や tmp のような曖昧な名前は、 書いた本人には分かっても、 他人には伝わりません。

• 変数・関数：スネークケース（snake_case）
• クラス：パスカルケース（PascalCase）
• 真偽値：is_xxx / has_xxx など意味が分かる名前

命名はセンスではなく、 読み手への配慮です。

docstringが適切に書かれているか

公開される関数やクラスには、 docstringが求められることが多いです。

処理の詳細をすべて書く必要はありませんが、 「何をする関数なのか」「どんな値を返すのか」 が分かるだけで、レビューの理解速度は一気に上がります。

こうしたスタイルや命名の改善は、 単なる見た目の話ではなく、 コード全体の品質を底上げする第一歩です。

実際にレビューで指摘されがちな改善ポイントや、 「どう直せばいいのか」を具体例付きで知りたい場合は、 次の記事も参考になります。

【リファクタリングとは？】初心者向けにコード改善の基本と具体例をやさしく解説！

リファクタリングはコードをより良くするための重要なプロセスです。本記事では、初心者向けにリファクタリングの意味、目的、タイミング、具体例、注意点までわかりやすく解説します。テストの重要性やパフォーマンス向上の考え方も紹介！

python.cbagames.jp

2025.06.23

次は、レビューで一番差がつきやすい 「設計・可読性」の観点を見ていきましょう。

3-2. 設計・可読性（レビューで一番差がつく）

スタイルや命名が整ってくると、 次に見られるのが設計と可読性です。 ここは初心者と実務経験者の差が最も出やすいポイントでもあります。

レビューでは、 「このコードは理解しやすいか？」 「あとから変更しやすいか？」 という視点でチェックされます。

1つの関数・クラスが責務を持ちすぎていないか

ありがちな指摘のひとつが、 「この関数、やっていることが多すぎませんか？」です。

関数やクラスは、 ひとつの役割に集中しているほうが、 読みやすく、テストもしやすくなります。

• 関数が長くなりすぎていないか
• 処理の流れを頭の中で追わなくても理解できるか
• 名前と中身が一致しているか

ネストが深くなりすぎていないか

if文やfor文が何重にもネストされていると、 一気に読みづらくなります。

レビューでは、 早期リターン（ガード節）が使えないか、 条件分岐を整理できないか、といった点がよく見られます。

同じ処理を何度も書いていないか（DRY原則）

似たようなコードがあちこちにあると、 将来の修正でミスが起きやすくなります。

レビューで 「ここ共通化できませんか？」 と聞かれる場合は、 DRY原則が意識されています。

マジックナンバーを直接書いていないか

意味の分からない数値が突然出てくると、 読み手は混乱します。

定数として名前を付けるだけで、 コードの意図は驚くほど分かりやすくなります。

こうした設計・可読性の考え方は、 レビュー対策というより エンジニアとして長く使える基礎体力です。

設計や読みやすさについて体系的に学びたい場合は、 定番書から一度インプットしておくのもおすすめです。

Clean Code

✅ Amazonでチェックする｜ ✅ 楽天でチェックする

次は、初心者のうちは見落としがちな パフォーマンスとデータ構造の視点を見ていきます。

3-3. パフォーマンス・データ構造

Pythonは書きやすい反面、 何も考えずに書くと遅くなりやすい言語でもあります。 レビューでは、処理速度そのものよりも、 「遅くなりやすい書き方をしていないか」 という視点でチェックされることが多いです。

データ構造の選び方が適切か

同じように見える処理でも、 データ構造が違うだけで パフォーマンスは大きく変わります。

• 検索が多いのにリストを使っていないか
• 変更しないデータをリストで持っていないか
• キーと値の対応関係をリストで無理に表現していないか

レビューでは、 set や dict を使った方が良いのでは？ という指摘がよく入ります。

無駄なリスト生成をしていないか

リスト内包表記は便利ですが、 大量データを扱う場合には注意が必要です。

レビューでは、 ジェネレータ式にできないか がチェックされることがあります。 メモリ消費を抑えられるかどうか、という視点です。

ループ内で重い処理をしていないか

次のようなコードは、 レビューで必ずと言っていいほど指摘されます。

• ループの中で毎回同じ計算をしている
• ループの中でデータベースやAPIを呼んでいる

いわゆる N+1問題 の兆候がないかどうかも、 レビュアーは敏感に見ています。

重要なのは、 「今は遅くないから大丈夫」 ではなく、 データ量が増えたときにどうなるか を想像できているかどうかです。

パフォーマンスの話は難しく感じがちですが、 レビューで見られるのは 最適化テクニックよりも 危険な書き方をしていないか という基本的な部分です。

次は、初心者のうちは特に見落としやすい セキュリティと安全性 の観点を見ていきましょう。

3-4. セキュリティ・安全性（初心者が見落としがち）

セキュリティと聞くと、 「自分にはまだ早い」「Webアプリの話でしょ？」 と思われがちですが、 レビューでは小さな危険の芽もきちんと見られます。

初心者のコードで多いのは、 「とりあえず動く」ことを優先した結果、 将来トラブルになりやすい書き方をしてしまうケースです。

外部入力をそのまま信用していないか

ファイル入力、ユーザー入力、APIレスポンスなど、 外部から来る値は常に疑う というのがレビューの基本姿勢です。

• 想定外の値が来たらどうなるか
• None や空文字が来ても壊れないか
• 型や範囲のチェックをしているか

レビューでは、 「この値、バリデーションしなくて大丈夫ですか？」 という形で指摘されることがよくあります。

秘密情報をコードに直接書いていないか

APIキーやパスワードを コードに直接書いてしまうのは、 初心者がやりがちなミスのひとつです。

レビューでは、 環境変数やSecrets管理を使うべきでは？ という指摘がほぼ確実に入ります。

「個人開発だから大丈夫」ではなく、 公開される可能性がある前提 で書かれているかが重要です。

例外処理を雑にしていないか

次のようなコードは、 レビューでかなり警戒されます。

• except Exception で全部まとめて捕まえている
• 例外を握りつぶして pass している
• エラーが起きても何もログに残らない

例外処理は、 「エラーを消すため」ではなく、 異常を正しく扱うため のものです。

このあたりの考え方は、 初心者のうちは特に分かりづらいため、 例外設計をテーマにした次の記事も参考になります。

Pythonの例外設計入門｜try/exceptを「どう設計するか」まで徹底解説

Pythonのtry/exceptを“書ける”から“設計できる”へ。例外を握りつぶさない方針、catch範囲の決め方、独自例外の作り方、raise from・ログ・リソース解放まで、実務で困らない例外設計をまとめて解説します。

python.cbagames.jp

2025.12.16

次は、レビューで 「このコード、ちゃんと守られている？」 と確認される テストとドキュメント の観点を見ていきます。

3-5. テスト・型ヒント・ドキュメント

コードがどれだけ綺麗に書かれていても、 「壊れない保証」がなければ安心して使えません。 レビューでは、 テストと将来の保守性という視点でも確認されます。

新しい処理にテストが追加されているか

レビューでよくある質問が、 「この変更、どこでテストされていますか？」です。

特に注意されるのは、 既存コードの修正なのにテストが増えていない ケースです。 バグ修正や仕様変更では、 再発防止のテストがあるかどうかが重視されます。

• 正常系だけで終わっていないか
• 境界値や異常系が考慮されているか
• テストが意図を説明する役割になっているか

型ヒントが適切に付いているか

Pythonは動的型付け言語ですが、 実務では型ヒントがあることを前提に レビューされるケースが増えています。

型ヒントがあるだけで、 次のようなメリットがあります。

• 関数の使い方が一目で分かる
• 意図しない値の混入を防ぎやすい
• IDEや静的解析ツールのサポートが強くなる

レビューでは、 「この引数、何が入る想定ですか？」 「Noneは来ますか？」 といった質問が、型ヒント不足から生まれます。

型ヒントの考え方や、 実務でどう使われているかを詳しく知りたい場合は、 次の記事が参考になります。

Python型ヒント実践入門｜Type Hintsでコード品質を上げる方法

ドキュメントが最低限そろっているか

READMEやdocstringがあるかどうかも、 レビューではしっかり見られます。

詳細な説明は不要でも、 「どう使うか」「何をしているか」 が分かる情報があるだけで、 レビューの理解スピードは大きく変わります。

ここまでで、 技術的なチェックポイントは一通りです。 次は少し視点を変えて、 レビューコメントとの向き合い方 について見ていきましょう。

4. レビューコメントの受け取り方・書き方（メンタル編）

コードレビューでつらく感じやすいのは、 技術そのものよりもコメントの受け取り方です。 特に初心者のうちは、 指摘＝否定された、と思ってしまいがちです。

でも実務のレビューで見ているのは、 人ではなくコードです。 この意識を持てるようになると、 レビューのストレスはかなり減ります。

人ではなく「コード」に向けた指摘だと理解する

良いレビューコメントは、 「あなたの書き方が悪い」ではなく、 「このコードだと将来ここで困りそう」 という視点で書かれています。

たとえば、 「この変数名だと意図が伝わりにくいかも」 という指摘は、 あなた自身を否定しているわけではありません。

「なぜそう思ったのか」を読み取る

コメントを読むときは、 修正内容だけでなく 理由に注目しましょう。

• 将来の変更を想定しているのか
• バグを防ぐ意図があるのか
• チームのルールに合わせているのか

この理由が分かるようになると、 同じ指摘を次からは自分で回避できるようになります。

コメントを書く側になったときの基本姿勢

いずれあなたがレビューする立場になることもあります。 そのときに意識したいのは、 相手が学べるコメントになっているかです。

• 断定的な表現を避ける
• 改善案や理由を添える
• 重要度が分かる書き方をする

多くのチームでは、 次のようなラベルを使って コメントの温度感を伝えます。

• MUST：修正が必須
• SHOULD：強く推奨される修正
• IMO：個人的な提案
• NITS：細かい指摘（タイポなど）
• LGTM：問題なし・承認

レビューは対立ではなく、 チームでコードを良くするための会話です。 この意識を持てるようになると、 レビューは一気に前向きなものになります。

次は最後に、 レビューを通して 一段上のエンジニアになるための視点 を整理します。

5. 「レビューされる側」から「レビューできる側」になるために

コードレビューに慣れてくると、 だんだんと 「なぜこの指摘が入ったのか」 が分かるようになってきます。

ここから先は、 ただレビューを受けるだけでなく、 自分自身がレビュー視点を持てるか が成長の分かれ道になります。

レビュー視点を持つとコードの書き方が変わる

「これ、あとから読んで分かるかな？」 「ここ、質問されそうだな」 と考えながらコードを書くようになると、 レビューでの指摘は自然と減っていきます。

これはテクニックというより、 読み手を意識する習慣です。

自分で自分のコードをレビューしてみる

プルリクエストを出す前に、 次のような視点で一度読み返してみてください。

• 初めて読む人でも理解できるか
• 関数名と処理内容が一致しているか
• この変更で壊れそうな場所はないか

これだけでも、 レビューで指摘される数はかなり減ります。

レビュー経験はそのまま市場価値につながる

コードレビューを通して身につく力は、 「Pythonが書ける」以上に評価されます。

設計を考える力、 他人のコードを読む力、 安全性や保守性を意識する力は、 実務で長く求められるスキルです。

最初は指摘が多くて当たり前です。 それは「伸びしろがある」というサインでもあります。

コードレビューを怖がらず、 成長のチャンスとして活用できるようになること。 それが、レビューされる側から レビューできる側へ進む第一歩です。

まとめ

コードレビューは、初心者にとっては 少し怖く感じるイベントかもしれません。 でも本質は、 コードの欠点を責める場ではなく、品質を高める仕組み です。

この記事では、Pythonのコードレビューで 実際によく見られているポイントを、 スタイル・設計・パフォーマンス・セキュリティ・テスト という観点から整理してきました。

• 動いているだけでは不十分
• 読みやすさ・変更しやすさが重視される
• 将来のバグを防ぐ視点が評価される

これらを知っているだけで、 レビューコメントの見え方は大きく変わります。 「なぜ指摘されたのか」が分かるようになると、 レビューはストレスではなく、 成長のためのヒント集になります。

最初から完璧である必要はありません。 レビューを通して少しずつ視点を身につけていくことが、 実務で信頼されるエンジニアへの近道です。

私自身も、何度もレビューで指摘されながら、 「あ、ここを見られていたんだ」 と気づくことで成長してきました。

この記事が、 コードレビューに対する不安を減らし、 一歩前向きに取り組むきっかけになれば嬉しいです。

よくある質問（Q&A）

1. はじめに｜コードを自動できれいに整えるには？

Pythonのコードって、書く人によってインデントの幅やスペースの使い方がちょっとずつ違ったりしますよね。「このコード、なんか読みにくいな……」と感じたことがある人も多いと思います。

でも実は、コードの「見た目」を自動できれいに整えてくれる便利なツールがあるんです！

また、コードを実行する前にエラーを見つけてくれるツールも存在します。これらをうまく使うことで、

• 自分の書いたコードがきれいに整って見やすくなる
• コードを動かす前にミスを発見できる
• チームで開発するときに「書き方のバラつき」を防げる

といったメリットが得られます。

Pythonには「コードフォーマッター」と呼ばれる整形ツールや、「静的解析ツール」と呼ばれるエラーチェックツールがあります。この記事では、それぞれの特徴や使い方、代表的なツール（autopep8、Black、flake8）を初心者向けにわかりやすく解説していきます。

コードをもっとキレイに、もっと安全に。そんな第一歩を一緒に踏み出してみましょう！

2. コードフォーマッターとは？｜見た目を整えるツール

コードフォーマッターってなに？

Pythonのコードは、スペースや改行の位置がとても大事です。たとえば、以下のようなコードを見てください。

def greet(name):print("Hello,",name)

これ、ちゃんと動きますが、ちょっと見づらいですよね？
でも、こんなふうに整形すると…

def greet(name):
    print("Hello,", name)

おお！だいぶ見やすくなりましたね。

このように、コードの「見た目」をルールに従って自動で整えてくれるツールが「コードフォーマッター」です。

PEP 8というルールに従うよ

Pythonには「PEP 8（ペップエイト）」というコードの書き方に関するガイドラインがあります。たとえば、

• インデントはスペース4つで揃える
• 1行は79文字以内が望ましい
• 演算子の前後にはスペースを入れる（例：x = 1 + 2）

など、読みやすさを大切にしたルールが決められています。

コードフォーマッターは、このPEP 8をもとにコードを整えてくれるんです。

有名なフォーマッター2つ：autopep8とBlack

Pythonでよく使われるコードフォーマッターには、主に次の2つがあります。

✅ autopep8（オートペップエイト）

• PEP 8にぴったり沿うようにコードを修正
• シンプルで軽いのが特徴
• 文字列のシングルクォート/ダブルクォートはそのまま残る（どちらでもOK）

✅ Black（ブラック）

• 少し厳しめなルールで整形
• たとえば、文字列リテラルをすべてダブルクォートに統一したりする
• きれいに整えられるけど、「少しクセが強い」部分もある

どちらもとても便利ですが、自分のスタイルや好みに合ったものを選ぶとよいですね！

autopep8の使い方（カンタン！）

1. コマンドでインストールします：

pip install autopep8

2. コードを整形するには、次のように実行します：

autopep8 -i script.py

これで、script.pyの内容が自動的にキレイに整えられます！
（-iは「その場で上書き」の意味です）

PyCharmでもフォーマットできる！

もしPyCharmというエディターを使っているなら、さらにラクです。
Windowsなら Ctrl + Alt + L、Macなら Option + Command + L を押すだけで、自動でフォーマットされます。

コードフォーマッターは、書いた後に一括でキレイに整える魔法のツールです。
初心者のうちは細かい書き方のルールを覚えきれないこともあるので、ぜひ活用してみてください！

3. 静的解析ツールとは？｜バグを未然に防ぐ

静的解析ってなに？

静的解析（せいてきかいせき）とは、Pythonのコードを実行せずにチェックして、エラーやバグの可能性を教えてくれるツールのことです。

たとえばこんなコード：

def add(a, b):
    return a + c  # ← c は定義されてない変数

このコードを実行するとエラーになりますが、静的解析ツールを使えば、実行する前に「ここおかしいよ」と教えてくれるんです。
とっても心強いですね！

なぜ必要なの？

Pythonは柔軟な言語なので、**「書けちゃうけど動かすとエラー」**ということがけっこうあります。
特にチーム開発や少し大きめのコードになると、思わぬミスに気づかずに進めてしまうことも…。

静的解析ツールを使うと、

• 未定義の変数の使用
• 使ってない変数の存在
• 引数の数が合っていない
• 無駄なインポート

などを、自動でチェックしてくれます。

有名な静的解析ツール：flake8

Pythonでよく使われる静的解析ツールの代表が、**flake8（フレークエイト）**です。

特徴としては、

• コードを実行せずに文法エラーやスタイル違反をチェック
• pycodestyleやmccabeなどのツールと連携して、細かい部分まで見てくれる
• とても軽くてシンプル

flake8の使い方（カンタン！）

1. インストールします：

pip install flake8

2. コマンドで解析します：

flake8 script.py

すると、もしscript.pyの中に問題があれば、行番号と内容つきで警告が表示されます。

例：

script.py:3:14: F821 undefined name 'z'

これは「3行目の14文字目にzという未定義の変数がありますよ」という意味です。

PyCharmでも静的解析できる！

PyCharmを使っている人は、すでに静的解析が自動で有効になっているかもしれません。

• 未定義の変数や文法エラーには赤いニョロニョロ（波線）
• 警告やアドバイスは黄色の線や電球マーク

PyCharmがエラーをリアルタイムで教えてくれるので、書いている最中に直せるのがとても便利です。

flake8とPyCharmの違いって？

flak8は、CI/CDと組み合わせてチームでの自動チェックに向いているのが強みです。
一方でPyCharmは、エディタ内での快適なコーディングをサポートしてくれます。

「静的解析ツール」は、Python初心者にもぜひ使ってほしいチェック機能です。
実行する前にミスを防げるので、安心してコードを書けるようになりますよ！

4. 自動化との相性｜CI/CDでの活用方法

そもそもCI/CDってなに？

まず最初に、「CI/CDってなに？」というところからお話ししますね。

• **CI（継続的インテグレーション）**は、プログラムのコードが変更されるたびに、自動でテストやチェックを行ってくれる仕組みのこと。
• **CD（継続的デリバリー）**は、そのコードを自動で本番環境に届けたりする流れのこと。

難しそうに聞こえるかもしれませんが、要は**「コードを書いたら、自動で動作確認やコードチェックをしてくれる便利な仕組み」**だと思ってください！

フォーマッターや静的解析ツールはCIと相性バツグン！

ここで登場するのが、先ほど紹介した autopep8 や flake8 などのツールです。これらは、**「自動で動かせるツール」**なので、CIと組み合わせるのにピッタリなんです！

例えばこんな流れ：

1. Aさんが新しい機能を作ってGitHubにプッシュ
2. GitHub Actions（CIツール）が動き出す
3. flake8で静的解析 → エラーがあればAさんに通知！
4. autopep8でコードを整形 → 書き方がきれいになってからマージ！

このように、コードの質を自動で守る仕組みができあがります。

PyCharmだけじゃ足りない理由

PyCharmの中でもコードチェックはできますが、それは開発者のPCの中だけでの話。

チームでの開発では、

• 「AさんはPyCharmだけど、BさんはVS Code」
• 「Cさんはチェックを忘れてプッシュしちゃった」

なんてことも起こりがちです。

CIに flake8 や black を組み込んでおけば、どのメンバーが書いたコードでも、ルール通りにチェック・整形できるようになります。

実際によく使われる構成例

CIツールとしては GitHub Actions が人気です。
Pythonのプロジェクトなら、こんなワークフローを設定することで自動チェックが可能になります：

# .github/workflows/lint.yml
name: Lint Check

on: [push, pull_request]

jobs:
  lint:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v3
      - name: Set up Python
        uses: actions/setup-python@v4
        with:
          python-version: '3.10'
      - name: Install flake8
        run: pip install flake8
      - name: Run flake8
        run: flake8 your_code_directory/

これを設定しておけば、プルリクエストのたびにflake8でコードチェックが走るようになります！

まとめ：自動化で「うっかりミス」をゼロに

CIにコードフォーマッターや静的解析を組み込むことで、

• 書き方のズレ
• 見落としたエラー
• 手動チェックの手間

を自動で解消できるようになります。

特にチーム開発や本番環境に出すプロジェクトでは、こうした自動化の仕組みが品質を支えてくれる大きな助けになります！

5. まとめ｜フォーマット整形と静的解析をうまく使い分けよう

ここまで、Pythonで使える「コードフォーマッター」と「静的解析ツール」について紹介してきました。

**フォーマッター（autopep8やBlack）**は、

• コードの見た目を整えて読みやすくしてくれる
• PEP 8というルールに従って自動で整形
• チーム全体のコードの統一感をキープできる

**静的解析ツール（flake8）**は、

• 実行前にバグの予兆や問題点をチェック
• コードの質を保つための頼れる味方
• エディタ外でもCIなどに組み込めて便利

というように、それぞれ違った役割でPython開発をより安全＆スムーズにしてくれる存在です。

✅どっちも使うのが最強！

たとえば、

• 書いてる途中は PyCharmのフォーマッター＆警告表示 に助けてもらって、
• プルリク前に Blackで自動整形、
• GitHub上で flake8を使ったCIチェックを走らせる

というように、うまく組み合わせて使うとミスを減らせて作業もラクになります！

✅初心者でも今すぐ使える！

どのツールもインストールしてコマンド1つで使えるので、初心者でもすぐに導入できます。

Pythonを書いていて、

「なんかコードがごちゃごちゃしてきたな…」
「エラーが出てからじゃ遅いな…」

と思ったら、**ぜひこの記事で紹介したツールを試してみてくださいね！

あわせて読みたい

コードの整形やチェックとあわせて、以下の関連記事もチェックしておくと、さらにレベルアップできます！

• 🔍 【Python入門】デバッガーの使い方をやさしく解説｜breakpoint関数・VS Code対応
  　→ コードをステップ実行しながら、ミスの原因をしっかり突き止める方法を解説！
• 🤖 VS CodeでAIを活用する方法（GitHub Copilot、MCPサーバー、AIエージェントなど）
  　→ VS CodeでAIにコード補完やエラーチェックを手伝ってもらう方法を紹介！
• ✅ Pythonでテストコードを書く方法｜初心者向けpytest入門ガイド
  　→ 静的解析と一緒に知っておきたい、自動テストの書き方がわかります！

よくある質問（Q&A）

1. はじめに｜Pythonではなぜインデントが重要なの？

Pythonを勉強し始めて、こんなエラーに戸惑ったことはありませんか？

if True:
print("こんにちは")

一見すると正しそうに見えるこのコード。
でも実行すると、次のようなエラーが表示されます。

IndentationError: expected an indented block

「え？スペルも合ってるし、構文も間違ってないはずなのに…」
そう感じた方、実はとても多いです。

このエラーの原因は、**Python特有のルールである「インデント（字下げ）」**にあります。
Pythonでは、インデントのズレ＝プログラムの意味のズレ。
たった数文字の空白が、エラーの原因になることも珍しくありません。

実際、Python初心者が最初につまずくポイントの上位が
**「インデントエラー」「タブとスペースの違い」**です。

この記事では、

• インデントとは何か？なぜPythonでは重要なのか
• スペースとタブの違い（どっちを使うべき？）
• IndentationErrorを確実に防ぐ書き方のルール

を、エラー例つきでやさしく解説していきます。

「インデントが怖くてPythonが進まない…」
そんな状態を今日で終わらせましょう。

2. インデントの基本ルール

Pythonでは、インデント（字下げ）がないとプログラムが動かないことがあります。ここでは、その基本ルールをわかりやすく紹介していきます！

◾ コロン（:）の後は必ずインデント！

Pythonで「条件分岐」や「繰り返し」などを使うときには、最後にコロン : をつけるのがルールです。
そして、その次の行では必ずインデントする必要があります。

たとえば if 文を書くときはこんな感じ：

if True:
    print("これは正しい書き方です")

ポイントはここ👇
✅ : をつけたら、次の行でインデントを入れる！

◾ インデントで「かたまり（ブロック）」を作る

Pythonでは、インデントがそのまま「処理のまとまり（ブロック）」を表します。
これはすごく大事です！

たとえば、こんなコードを見てください。

if True:
    print("A")
    print("B")
print("C")

この場合、

• 「A」と「B」は if の中の処理（インデントがある）
• 「C」は if の外の処理（インデントがない）

になります。
つまり、True だったら A と B は表示されるけど、C はそのあとに必ず実行されます。

◾ インデントしないとエラーになる！

インデントがないと、Pythonはどの処理がどこに属しているのか分からなくなってしまいます。

たとえばこんなコード：

if True:
print("こんにちは")  # インデントなし！

これは実行するとこうなります：

IndentationError: expected an indented block

Python先生に「ブロックが見つかりませんよ〜」って怒られちゃうんですね。

◾ インデントは何個分？スペース？タブ？

基本的には「スペース4つ」でインデントするのが、Pythonの公式ルール（PEP8）です。
タブも使えますが、スペースの方がおすすめです（この理由は次の章でくわしく紹介します！）。

✅ まとめ：インデントの3つの鉄則

1. : のあとには必ずインデント！
2. インデントでブロック（かたまり）を作る！
3. インデントを間違えるとすぐエラー！

3. スペースとタブの違いとは？

Pythonでは、インデントを「スペース」でも「タブ」でも作ることができます。
でも、ここにはちょっとした落とし穴があるんです！

◾ スペースとタブってなに？

まず、基本から確認しましょう。

• スペース：キーボードの「スペースキー（空白）」を1回押したときに入る空白。
• タブ：キーボードの「Tabキー」を押すと入る、ちょっと広い空白。

見た目は似ていますが、**Pythonにとっては「別物」**です！

◾ PEP8では「スペース4つ」がルール！

Pythonには「PEP8（ペップエイト）」というコードの書き方ガイドがあります。
この中で、インデントについては次のように決められています。

✅ インデントは「スペース4つ」を使いましょう

つまり、Tabキーは使わず、スペースを4回押すのが正しいやり方です。

◾ タブを使っても動くの？→一応動くけど非推奨！

たしかに、Pythonはタブでもインデントを認識します。

if True:
	print("タブでも動くことは動く")

でも…ここで問題が！

◾ タブとスペースを混ぜるとエラーになる！

インデントにタブとスペースが混ざってしまうと、エラーになることがあります。

if True:
    print("スペースの行")
	print("タブの行")  # ← ここで混在！

このようなコードを実行すると、こんなエラーが出ます：

TabError: inconsistent use of tabs and spaces in indentation

Pythonは「同じ種類のインデントで統一してね！」と教えてくれてるんですね。

◾ エディタの設定で「スペース」に統一しよう！

インデントのミスを防ぐためには、使っているエディタ（VS Code や PyCharmなど）で、

「Tabキーを押したら、スペース4つにする」設定

をしておくのがおすすめです！

✅ まとめ：スペース vs タブ、どっちがいい？

→ 結論：スペース4つでインデントしよう！

4. 実例で学ぶインデントミス

Python初心者がよくやってしまうインデントのミス。
ここでは、実際によくあるエラー例を紹介しながら、「どこが間違いなのか？どう直せばいいのか？」をわかりやすく解説していきます！

◾ if文でのインデントミス

age = 18

if age >= 18:
print("大人です")

このコード、見た目はシンプルですが…エラーになります！

IndentationError: expected an indented block

なぜかというと、if のあとにインデントがないからです。

✅ 正しい書き方：

age = 18

if age >= 18:
    print("大人です")

「if文の条件がTrueだったときに実行したい処理」は、インデントでひとつ下げるのがルールでしたね！

◾ forループでのインデントミス

for i in range(3):
print(i)

これもNG！

IndentationError: expected an indented block after 'for' statement

for の後の処理が、インデントされていないのが原因です。

✅ 正しい書き方：

for i in range(3):
    print(i)

ループ処理の中身はインデントして書く。これがPythonのルールです。

◾ 関数定義の中でのミス

def hello():
print("こんにちは！")

こちらもエラーです。

IndentationError: expected an indented block

Pythonは、関数の中身もインデントで書く必要があります。

✅ 正しい書き方：

def hello():
    print("こんにちは！")

◾ インデントをうっかりズラした例（まぎらわしい！）

for i in range(3):
  print("スペース2個")
    print("スペース4個")

このコード、見た目ではちょっとわかりにくいですが、インデントがバラバラになっています。

IndentationError: unexpected indent

Pythonはとても厳密にスペースの数を見ているので、「全部スペースでも、数が違えばエラー」です！

✅ こうやって直そう！インデントエラーの対策

• すべてのインデントを「スペース4つ」に統一しよう
• エディタの設定で「Tabキー＝スペース4つ」にする
• インデントの「見た目」ではなく、「実際の文字」で判断しよう（不可視文字を表示する設定も便利！）

5. エディタ設定でインデントミスを防ぐ方法

ここまで読んで「インデント、けっこう大事なんだなぁ」と感じていただけたと思います。
でも、手作業で毎回スペース4つを入れるのって、ちょっと面倒ですよね？

そんなときは、Pythonにやさしいエディタ（VS Code など）を使えば、ほぼ自動で解決できます！

◾ おすすめエディタ：VS Code（Visual Studio Code）

無料で使えて、Pythonにもバッチリ対応しているのが「VS Code」。
Python初心者からプロまで、たくさんの人が使っています。

◾ VS Codeで「Tabキーをスペース4つに変える」設定方法

1. VS Codeのメニューから「設定（Settings）」を開く
2. 検索窓に tab と入力
3. 「Insert Spaces（タブをスペースに変換）」を ON にする
4. 「Tab Size」を 4 に設定する

これだけで、Tabキーを押したら自動でスペース4つが入力されるようになります！

◾ 自動整形ツールでキレイなインデントを保つ！

Pythonのコードを一発でキレイにしてくれる「コード整形ツール」も便利です。

✅ よく使われる整形ツール

◾ VS Codeにautopep8を入れる手順（かんたん！）

1. Python拡張機能を入れておく（インストール済みでOK）
2. ターミナルで以下を実行：

pip install autopep8

3. VS Codeで「Shift + 右クリック → フォーマット」を選ぶと、インデントが整います！

◾ こんな設定もおすすめ！

• 保存時に自動フォーマット：設定で Format On Save をONにすると、保存するたびにコードが整えられます。
• 不可視文字の表示：スペースやタブの違いを目で確認できるようになります。

✅ まとめ：ツールでインデントを味方につけよう！

• 手動でスペース4つは大変→エディタで自動化！
• VS Codeの設定を整えれば、インデントミスとサヨナラできる
• 自動整形ツールを使えば、コードの見た目もプロっぽくなる！

6. まとめ｜インデントに強くなればPythonが楽しくなる！

Pythonでは、インデント（字下げ）がプログラムの命とも言える大事なルールです。

他の言語のように「{ }」でブロックを囲う代わりに、スペースやタブのインデントだけで処理のまとまりを表現するという、ちょっと変わった特徴があります。

でも、そのおかげで見た目がスッキリしたコードが書けるのもPythonの魅力なんです！

✅ この記事で学んだこと

• Pythonでは インデントが文法の一部
• インデントがないと IndentationError に
• スペース4つが公式推奨（PEP8）
• タブとスペースを混ぜるとエラーになる
• VS Codeなどのエディタで インデントミスは防げる

✅ これからPythonを書くときは…

🔸 if文やfor文のあとには「スペース4つ」でインデント
🔸 コード整形ツールでキレイに保つ
🔸 インデントが変だな？と思ったら、エディタの「不可視文字を表示」でチェック！

「インデント」でつまずいたあなたも、これで一歩前進です！
Pythonの世界をもっと楽しんでくださいね✨

あわせて読みたい｜インデントの理解をもっと深めたい人へ

以下の記事も、Python初心者がつまずきやすいポイントをやさしく解説しています。あわせて読んでおくと、よりスムーズにステップアップできますよ！

• 🔹 【初心者向け】SyntaxErrorとは？よくある書き間違いと直し方を徹底解説
• 🔹 Python初心者がよく出会う「NameError」と「IndentationError」の原因と解決法まとめ
• 🔹 【Python入門2】Pythonの基本構文をやさしく解説｜改行・インデント・エラー対応まで初心者向けに丁寧に紹介
• 🔹 Pythonのprintデバッグ活用術｜初心者でもできるエラー解決の第一歩

よくある質問（Q&A）

1. はじめに｜Python初心者が最初につまずくポイントとは？

こんにちは！
この記事では、Pythonを初めて学ぶ高校生やプログラミング初心者の方に向けて、基本的な構文や書き方をやさしく解説していきます。

Pythonはシンプルで読みやすい構文が特長の、人気の高いプログラミング言語です。AIやWeb開発、データ分析など、いろんな分野で使われています。ですが、いざ書いてみると「なぜか動かない…」「意味がわからないエラーが出る…」と、最初の壁にぶつかることも多いんです。

特に、こんなことで困った経験ありませんか？

• SyntaxErrorやIndentationErrorってなに？
• if文を書いたのに、なぜか動かない…
• インデントってどこまで下げればいいの？

じつはこれ、Pythonならではの「ルール」を知らないと起こりやすい失敗なんです。

たとえば、Pythonでは「インデント（字下げ）」の位置がコードの意味に影響します。他の言語ではあまり見かけない特徴なので、初心者が最初につまずくポイントになりがちです。

でも大丈夫！この記事では、以下の3つをわかりやすく解説していきます。

1. Pythonの基本構文（改行やインデントのルール）
2. PEP8というスタイルガイドに沿った、読みやすいコードの書き方
3. エラーメッセージの読み解き方と対処法

初心者の方でも、実際のコード例を見ながら学べるように、やさしい言葉と具体例を使って進めていきます。
「わからない…」を「できた！」に変える第一歩として、ぜひ読み進めてみてくださいね！

👉 最初のステップは、インデントと改行の基本ルールを知ることから！詳しく見ていきましょう。

2. Pythonの基本構文をマスターしよう

Pythonを使いこなすためには、「文法のルール」をしっかり理解することが大切です。とくにインデントや改行のルールは、Python独特で初心者がつまずきやすいポイントでもあります。

ここでは、Pythonを書く上で必ず知っておきたい基本構文を、順番にやさしく紹介していきます。

2-1. 改行とインデントのルール

🔸 Pythonは“見た目”が命！

Pythonでは「どこで処理が始まり、どこで終わるのか」をインデント（字下げ）で表現します。
たとえば、if文を書いたときはこんなふうになります：

x = 10

if x > 5:
    print("5より大きいです")

ポイントはこの「print」の前のスペース4つ。これがインデントです。

❌ インデントを忘れると…

if x > 5:
print("エラーになります！")  # ← エラー！

このように**インデントがないだけでエラー（IndentationError）**になってしまいます。
インデントの深さは スペース4つが基本。Tabキーではなく、スペースを使うのがPEP8というルールでも推奨されています。

2-2. Pythonでよく使う基本構文

🟢 変数の代入

name = "Taro"
age = 18

Pythonは型を書かなくてもOK！文字列や数値もシンプルに書けます。

🟢 条件分岐（if文）

if age >= 18:
    print("大人です")
else:
    print("未成年です")

コロン「:`」のあとにインデントを忘れずに！

🟢 繰り返し（for文）

for i in range(5):
    print(i)

range(5)は「0〜4」まで繰り返す命令。インデントでprint(i)が繰り返し対象だと伝えています。

2-3. コメントを書こう（#マーク）

コードの中にメモを残したいときは、#（シャープ）を使ってコメントを書きます：

# これは年齢を比較するプログラムです
if age >= 20:
    print("飲酒OK")

コメントはプログラムの動作には影響せず、あとで見返したときのヒントになります。
自分が書いたコードでも、時間が経つと「これ何だっけ？」となるので、コメントはこまめに入れておくのがコツです！

🧑‍🏫 ワンポイントまとめ！

3. PEP8とは？読みやすいコードを書くためのガイドライン

Pythonには、**読みやすくてキレイなコードを書くための“ルールブック”**があるのをご存じですか？
それが PEP8（ペップエイト） というスタイルガイドです。

この章では、「PEP8って何？」「守らないとどうなるの？」といった疑問に答えながら、読みやすくてトラブルの少ないコードを書くコツを紹介していきます。

3-1. PEP8ってなに？

PEP8（Python Enhancement Proposal 8）は、Pythonの公式なコーディングスタイル集です。

難しく聞こえるかもしれませんが、要は「みんなが読みやすいように、こう書こうね！」というお作法のまとめだと思ってください。

たとえば：

• インデントはスペース4つにしよう
• 長すぎる1行はやめよう（基本は79文字以内）
• 変数名はわかりやすくつけよう（例：num_items など）

こうしたルールに沿うことで、自分も他人もわかりやすいコードになります。

3-2. 実際によくあるPEP8ルールまとめ

3-3. PEP8に違反するとどうなるの？

実際、PEP8に従わないからといってエラーになることはありません。
でも、読みづらいコードは以下のような問題を引き起こします：

• 他の人がコードを読めなくなる（チームでの開発に不向き）
• 自分でも後で意味がわからなくなる
• 間違いを見つけにくくなる（バグの温床）

たとえばこちら：

def a(x):return x+1

これ、動くけど……見にくいですよね。
PEP8に沿って書くとこうなります：

def add_one(x):
    return x + 1

たった数文字の違いで、グッと読みやすくなるんです。

3-4. PEP8チェックツールを使おう

初心者でも簡単にPEP8に沿ったコードを書けるようになるツールもあります：

• flake8：PythonのコードにエラーやPEP8違反がないかチェックしてくれる
• Black：自動でPEP8に整形してくれるフォーマッター

どちらも無料で使えるので、プログラムに慣れてきたら試してみてくださいね！

🧑‍🏫 ワンポイントまとめ！

• PEP8は「Pythonを書くときのマナー帳」
• 読みやすく、ミスの少ないコードを書くために大切
• 自分のためにも、未来の自分や他人のためにも、「見やすいコード」を意識してみよう！

4. エラーメッセージを味方につけよう

Pythonを書いていてよくあるのが、**プログラムが途中で止まってしまう「エラー」**です。
最初は「なんか怖い…」「全部英語で意味わからん…」と思うかもしれません。

でも実は、エラーメッセージは“先生のヒント”のようなものなんです。
ここでは、初心者がよく出会うエラーと、その読み解き方、解決方法をやさしく解説していきます！

4-1. Pythonでよくあるエラー3選

❌ SyntaxError（文法エラー）

文法のルールに違反しているときに出ます。

print("こんにちは"

🔽 エラー表示の一例：

SyntaxError: '(' was never closed

➡ カッコが閉じられていないという意味。「閉じカッコがないよ！」と教えてくれています。

❌ IndentationError（インデントのエラー）

インデントがずれていたり、足りなかったりすると出るエラーです。

if True:
print("Hello")  # ← インデントなしでエラー！

🔽 エラー表示の一例：

IndentationError: expected an indented block

➡ 「インデントが必要なのに入ってないよ！」という指摘。

❌ NameError（名前が見つからない）

変数名が間違っているときに出ます。

print(score)  # まだscoreを定義してない

🔽 エラー表示の一例：

NameError: name 'score' is not defined

➡ 「scoreっていう名前の変数、どこにもないよ」という意味です。

4-2. エラーの「どこを見るか」を覚えよう！

エラーメッセージには「エラーの種類」「問題の場所」「説明」が含まれています：

File "main.py", line 3
    print("Hello"
         ^
SyntaxError: '(' was never closed

💡チェックポイント：

1. ファイル名と行番号：「どこでエラーが起きたか」がわかる！
2. エラーの種類：SyntaxError などの名前を覚えると強くなる！
3. 説明文：ヒントが載ってるので、Google翻訳などを活用しよう！

4-3. エラーは「失敗」じゃなく「学び」

最初はエラーが出るたびに落ち込むかもしれませんが、エラーを直す力＝プログラミング力です。
うまくいかない → 調べて直す → 動いた！
この流れを何回か経験するうちに、どんどん上達していきます。

むしろ、「エラーの意味が少しわかってきたかも」と思えたら、あなたはもう初心者を卒業し始めています！

🧑‍🏫 ワンポイントまとめ！

• エラーは“怒られてる”のではなく、“助けてもらっている”
• よく出るエラーの種類を知っておくだけで安心感アップ！
• エラーメッセージの内容は「宝の地図」みたいなもの

5. 実践編｜間違い探しで学ぶPythonの構文

ここまでで、Pythonの基本ルールやエラーの読み方を学んできました。
でも、知識だけでなく「実際に間違っているコードを直す力」も大切です！

この章では、あえて“間違ったコード”を見て、それをどう直すかを一緒に考えていきましょう。
まるで間違い探しゲームのように、楽しみながら学べますよ！

5-1. おかしなPythonコードを直してみよう！

🧩 問題1：インデントがバラバラ

if True:
print("こんにちは")
    print("Python楽しい！")

💭 このコード、どこが間違っているかわかりますか？

👇 正しい書き方はこちら：

if True:
    print("こんにちは")
    print("Python楽しい！")

🔍 ポイント：

• ifの中の処理は、すべて**同じインデント幅（スペース4つ）**にそろえましょう！

🧩 問題2：コロンを忘れてる！

x = 10
if x > 5
    print("5より大きい")

👇 正しい書き方はこちら：

x = 10
if x > 5:
    print("5より大きい")

🔍 ポイント：

• if文やfor文のあとには「:（コロン）」が必須！

🧩 問題3：変数が定義されていない

print(total_price)

👇 修正するには、変数をちゃんと用意しましょう：

total_price = 3000
print(total_price)

🔍 ポイント：

• 変数は使う前に必ず定義すること！
• NameErrorが出たら「変数、ちゃんと作った？」を疑いましょう。

5-2. PEP8を意識して書き直してみよう！

こちらのコード、動きますが読みにくいです：

def tax(p):return p*1.1
print(tax(1000))

👇 PEP8に従って、読みやすく整えると：

def calculate_tax(price):
    return price * 1.1

print(calculate_tax(1000))

🔍 ポイント：

• 関数名・引数名は意味がわかるように
• 処理と処理の間に空行を入れて見やすく

🧑‍🏫 ワンポイントまとめ！

• 「間違いを直す」練習は、成長への一番の近道！
• エラーを見つけて修正できる力は、プログラミングの武器！
• PEP8を意識するだけで、コードの読みやすさがグッとアップ！

6. まとめ｜ルールを知れば怖くない、Pythonの第一歩

ここまで、Python初心者がつまずきやすいポイントを中心に、基本的な構文やエラーの読み方、そして読みやすいコードの書き方（PEP8）について学んできました。

最初は「インデントって何？」「なんでこんなエラーが出るの？」と戸惑うことも多いと思います。
でも、Pythonには明確なルールがあり、それを知っていれば自然とコードが書けるようになります。

💡 この記事で学んだことをふり返ろう！

• Pythonは“インデント”と“改行”が命
  　→ コードの形で「処理のまとまり」を表す
• PEP8に沿えば、読みやすいコードになる
  　→ 未来の自分や他人が見てもわかるコードを目指そう！
• エラーメッセージは味方にしよう
  　→ 問題の場所や内容を教えてくれる、大事なヒント！
• 間違い探しは最高の練習
  　→ 実践を通じて理解が深まる！

🔰 おわりに

Pythonの学習は、「失敗→理解→成功」のくり返しです。
エラーが出たときに「わからない」で止まらず、「なんで？」と調べていく姿勢が、プログラミングの上達にはとても大切です。

焦らず、ひとつひとつ、できることを増やしていきましょう。
あなたの第一歩が、これからの大きな成長につながるはずです！

次は、実際に自分でコードを書いてみたり、簡単な課題に挑戦したりしてみてください。
「print」1行から始まったPythonの道が、きっと楽しく広がっていきますよ！

【Python入門3】Pythonの変数とは？命名ルールと使い方を初心者でもわかるように解説！

Python初心者向けに「変数」の基本をわかりやすく解説。命名ルールや代入・参照のステップ、実際のサンプルコードまで丁寧に紹介します。

python.cbagames.jp

2025.06.02

よくある質問（Q&A）