🧑‍🏫
AI の学習モード、どれを選ぶ？ーChatGPT と Claude と Gemini を実際に比較した結果

2026/01/11に公開
 はじめにChatGPT, Claude, Gemini の各 AI モデルには、学習をサポートするための「学習モード」が実装されています。これらのモードを選択すると、AI は直接答えを教えるのではなく、ヒントを与えながら段階的に理解を深められるよう、ガイド付きの対話を生成します。
しかし、3つのモデルそれぞれに学習モードが存在するため、「どのモデルを選べばいいのか」と迷う方も多いのではないでしょうか。実際に使ってみると、各モデルによって対話スタイルやアプローチが異なり、学習の目的や好みによって最適な選択が変わってきます。
本記事では、ChatGPT, Claude, Gemini の学習モードを実際に使用し、同じトピックで比較検証した結果をまとめます。

 TL;DR3つの AI モデルの学習モードを比較した結果、それぞれに明確な特徴の違いがあることがわかりました。


モデル名
質問スタイル
説明スタイル
学習アプローチ
適している学習シーン


ChatGPT
選択肢（A-D）で素早く状況把握
簡潔で要点を押さえた説明
クイズ形式で効率的に進行
効率的に要点を押さえたいとき

Claude
複数質問で現状を深く理解
詳細で丁寧な説明
思考を促す質問で深い理解を促進
深く理解し、思考を整理したいとき

Gemini
選択肢で学習方向を委ねる
比喩や絵文字で親しみやすく
ステップバイステップで実践的
初心者で、取っ掛かりが欲しいとき

結論

効率的に要点を押さえたい → ChatGPT

深く理解し、思考を整理したい → Claude

初心者で、取っ掛かりが欲しい → Gemini

 各モデルの学習モードの設定方法と、今回の記事で設定したモデルについて
 ChatGPTChatGPT の場合は、＋ボタンから「あらゆる学びをサポート」を選択すると学習モードになります。

今回の記事では、 ChatGPT 5.2 Thinking（Extended thinking） を用いました。

 Claude の学習モードClaude の場合は、モードではなくスタイルとして提供されています。

＋ボタンから「スタイルを使用」を選択して、「学習」スタイルを選択してください。

今回の記事では、 Opus 4.5 を用いました。

また、Extended Thinking（じっくり考える）モードを適用させました。

 Gemini の学習モードGemini の場合は、ツールボタンから「ガイド付き学習」を選択すると学習モードになります。

今回の記事では、 3.0 Pro を用いました。

 実際に試してみた同じトピックで各モデルの学習モードを試し、その違いを比較しました。

 Repository パターンについてアーキテクチャ設計を学ぶ初心者になりきって、デザインパターンである「Repository パターン」について、各モデルに学習したいと伝えました。
最初に入力したプロンプトは全て共通で「Repository パターンについて学習したいです」です。
コードブロックに囲まれている方が AI の回答で、地の文がユーザー側のプロンプトです。

 ChatGPT の場合了解です。まず軽く状況を知りたいです（1つだけ聞きます）。

**あなたは今、Repositoryパターンをどの文脈で学びたいですか？**  
A) DDD/クリーンアーキテクチャとして理解したい  
B) DBアクセスをテストしやすくしたい（モックしたい）  
C) Goでの実装パターンを知りたい（interface/struct）  
D) なんとなくよく出てくるので整理したい

A〜Dのどれが一番近いですか？（複数でもOK）
D, A です
OK、じゃあ **「なんとなく出てくるRepository」→「DDD/クリーンアーキでの位置づけ」** の順で、短く噛み砕いていきます。

## Repositoryパターンって一言で？

**「ドメイン（ビジネス側）が、DBなどの保存先を意識せずに“出し入れ”できるようにするための窓口」**です。  
イメージは **“コレクション（配列）っぽく扱える永続化の口”**。

- ドメイン/ユースケース側：「ユーザーをIDで取得して、保存したい」
    
- でも実際はDB/Redis/API…保存先は色々
    
- そこで Repository が「取得/保存」という _意図_ だけを公開して、裏側を隠す
    

## DDD/クリーンアーキだとどこに置く？

ここが重要で、**Repositoryは“境界”にまたがる概念**です。

- **インターフェース（契約）**：内側（ドメイン or アプリ層）に置く  
    → 「こういう取得/保存が欲しい」という要求を内側が定義する
    
- **実装（DBでの取得/保存）**：外側（インフラ層）に置く  
    → 具体的にSQL叩くなど
    

つまり **依存の向き**はこう：

> アプリ/ドメイン ←（interface）→ インフラ実装  
> で、インフラが内側のinterfaceを実装する（依存逆転）。

## Repositoryが解決したい痛み（DDD寄り）

- ドメインやユースケースが **SQL/ORM/テーブル構造** に汚染されるのを防ぐ
    
- 「保存先が変わる（DB→API等）」が起きても、影響範囲を小さくする
    
- 取得/保存の“意図”を **ユビキタス言語** っぽく表現できる  
    例：`FindByEmail(email)` とか（ただしやりすぎ注意）
    

---

ここまでを踏まえて、次に進む前に1つだけ確認させてください。

**あなたの中で「Repositoryって結局DAOと何が違うの？」って疑問はありますか？**（Yes/No）
Yes
いいね、そこが一番ひっかかる所です。

まず整理のために、あなたの理解を聞きたい（1つだけ）。  
**いまの感覚で「DAO」って何をするものだと思ってます？**（一言でOK）
SQL を書かずにデータアクセスができる
OK、その理解だと **「DAO＝DBアクセスを隠すやつ」** って感じですね。そこから繋げると違いが見えてきます。

## DAOとRepositoryの違い（芯だけ）

- **DAO**：_DB中心_（テーブル/SQLの都合に寄りやすい）  
    → 「usersテーブルから取る」「JOINしてDTOで返す」みたいな発想になりがち
    
- **Repository**：_ドメイン中心_（エンティティ/集約を出し入れする）  
    → 「Userという概念を、取得・保存する」発想
    

言い換えると：

- DAOは **“データベースのためのAPI”**
    
- Repositoryは **“ドメインモデルのためのコレクション風API”**
    

## 具体例で差が出るところ

たとえば「注文(Order)」が複数テーブルにまたがるとします。

- DAOだと  
    `OrderDao.selectOrderRow()`  
    `OrderItemDao.selectByOrderId()`  
    みたいに **テーブル単位**でバラけやすい
    
- Repositoryだと  
    `OrderRepository.FindById(id) -> Order(集約)`  
    みたいに **“注文という塊（集約）”** で返す/保存する発想になりやすい  
    （裏でJOINするか、複数クエリかは隠蔽）
    

## ありがちな誤解も1つ

あなたの言った「SQLを書かずにアクセスできる」は、実は **RepositoryでもDAOでも起こり得る**（ORM使えばどっちでも可能）。  
違いは「SQLを書く/書かない」より **“何を中心に設計するか”** です。

---

ここでミニチェック（1問、選択式）：

**Repositoryが扱うのに一番しっくりくるのはどれ？**  
A) テーブル行（row）  
B) DTO（画面用の詰め合わせ）  
C) ドメインのエンティティ/集約（例：Order全体）

どれだと思う？
C
その通り。じゃあ次の一歩に進めます。

## Repositoryで「DDDっぽくなる」ポイント

Repositoryが扱うのは **集約（Aggregate）単位** が基本です。  
例：`Order` 集約なら、`OrderRepository` が `Order` を出し入れする。

- ✅ `OrderRepository.FindById(id) -> Order`
    
- ✅ `OrderRepository.Save(order)`
    
- ❌ `OrderRepository.FindOrderItemsByOrderId(id)`（集約の内部パーツ取得はやりがちだけどDDD的には匂い）
    

## でも現実：検索条件いろいろ欲しい問題

ここで多くの人が悩みます。「一覧画面用にJOINしてDTO返したい」みたいなやつ。

DDD/クリーンアーキ寄りだとよくある整理は：

- **Repository：集約の取得/保存（コマンド寄り）**
    
- **Query Service / Read Model：一覧・検索（クエリ寄り）**  
    （CQRSの軽量版みたいな分け方）
    

つまり「Repositoryに何でも詰め込む」とDAO化しがちです。

---

ここまで理解できたか確認したいので、1つだけ質問。

**あなたの現場（または想定）では、Repositoryをどの層で使いたいですか？**  
A) Controller直下  
B) UseCase/Application層（サービス）  
C) Domain層の中  
D) まだ層分け自体が曖昧

どれが一番近いですか？
※Repository パターン自体の説明から逸脱してきそうだったので、ここで会話をやめました。

 Claude の場合Repository パターンを学びたいとのこと、素晴らしいですね！

まずあなたの現状を教えていただけますか？

1. **今の知識レベル** — Repository パターンについて、すでに聞いたことがある、なんとなく知っている、それとも初めて触れる概念ですか？
    
2. **背景** — 何かきっかけがありましたか？例えば、実際のプロジェクトで使いたい、コードレビューで指摘された、書籍や記事で見かけた、など。
    
3. **関連知識** — デザインパターン全般や、レイヤードアーキテクチャ（層構造）について触れたことはありますか？
    

これらを教えていただければ、あなたに合った形で一緒に学んでいけると思います！
聞いたことはありますが、実装したことはありません。
実際のプロジェクトで使いたいと思いました
アーキテクチャの設計はしたことがありません
なるほど、実際のプロジェクトで使いたいという実践的な動機があるのは良いですね！

では、Repository パターンの「なぜ必要か」を理解するところから始めましょう。

---

まず考えてみてほしいのですが、今あなたがデータベースからユーザー情報を取得するコードを書くとしたら、どこに書きますか？

例えば、こんな状況を想像してください：

> 「ユーザーIDを指定して、そのユーザーの情報を取得し、画面に表示する」

このとき、SQLを実行するコード（または ORM を使うコード）は、どのあたりに置くイメージがありますか？

- 画面表示を担当するコードの中？
- 別のファイルやクラスに分ける？
- 特に意識したことがない？

今のあなたの感覚や、普段どうしているかを教えてください。そこから Repository パターンが解決しようとしている問題が見えてくると思います。
特に意識したことはありませんが、一つのファイル（クラス）に何でもかんでも実装するのはメンテナンス性が悪いのかなと感じています
その直感、とても大事です！まさにそこが Repository パターンの出発点になります。

---

では、その「メンテナンス性が悪い」を具体的にイメージしてみましょう。

例えば、こんなコードがあったとします（擬似コードです）：

```python
class UserScreen:
    def show_user_profile(self, user_id):
        # データベースに接続
        connection = Database.connect("mysql://...")
        
        # SQLを実行してユーザー情報を取得
        result = connection.execute("SELECT * FROM users WHERE id = ?", user_id)
        user = result.fetch_one()
        
        # 画面に表示
        self.display_name(user.name)
        self.display_email(user.email)
```

この `UserScreen` クラスは、「画面表示」と「データ取得」の両方を担当しています。

ここで質問です。もし以下のような変更が発生したら、このコードはどうなりそうですか？

1. **データベースを MySQL から PostgreSQL に変えることになった**
2. **別の画面でも同じユーザー情報を取得したくなった**

それぞれ、どんな問題が起きそうか、想像してみてください。
connection の実装を変更する必要がある。
同じようなコードを書くことになる
その通りです！まさにその2つが核心的な問題です。

まとめると：

- **変更の影響が広がる** — DBの種類を変えただけなのに、画面のコードを修正しなければならない
- **コードの重複** — 同じ SQL を複数の場所に書くことになる

---

では次のステップです。

あなたが今指摘した2つの問題を解決するとしたら、どういう構造にすれば良さそうですか？

ヒントとして、こう考えてみてください：

> 「ユーザー情報の取得」という処理を、`UserScreen` 以外の誰かに任せるとしたら？

どんな役割を持ったクラス（またはファイル）を作れば、先ほどの問題が解消できそうでしょうか？
Repository クラスですか？
はい、その通りです！名前としては Repository クラスですね。

ただ、もう少し深掘りさせてください。

---

今「Repository クラス」という名前は出てきましたが、ここで大事なのは「そのクラスが何をする役割なのか」です。

先ほどの例をもう一度見てみましょう：

```python
class UserScreen:
    def show_user_profile(self, user_id):
        # ① データベースに接続
        # ② SQLを実行してユーザー情報を取得
        # ③ 画面に表示
```

この中から「Repository クラス」に切り出すとしたら、①②③のどこまでを任せるべきだと思いますか？

そして、`UserScreen` には何が残るでしょうか？
1, 2 な気がしました UserScreen には 3 の処理が残ります
その通りです！素晴らしい判断です。

---

では、その考えを実際のコードにしてみましょう。

**Before（すべて UserScreen に書いていた状態）：**

```python
class UserScreen:
    def show_user_profile(self, user_id):
        connection = Database.connect("mysql://...")
        result = connection.execute("SELECT * FROM users WHERE id = ?", user_id)
        user = result.fetch_one()
        
        self.display_name(user.name)
        self.display_email(user.email)
```

**After（Repository に分離した状態）：**

```python
class UserRepository:
    def find_by_id(self, user_id):
        connection = Database.connect("mysql://...")
        result = connection.execute("SELECT * FROM users WHERE id = ?", user_id)
        return result.fetch_one()


class UserScreen:
    def __init__(self):
        self.user_repository = UserRepository()
    
    def show_user_profile(self, user_id):
        user = self.user_repository.find_by_id(user_id)
        
        self.display_name(user.name)
        self.display_email(user.email)
```

---

さて、ここで先ほど挙げた2つの問題を振り返ってみてください：

1. **MySQL から PostgreSQL に変えることになった**
2. **別の画面でも同じユーザー情報を取得したくなった**

After のコード構造だと、これらの問題はどう解決されていますか？
UserRepository のコードを変更するだけで済む
UserRepository::find_by_id を利用するだけで済む
完璧です！Repository パターンの核心的なメリットを理解できましたね。

---

ここで一度整理しましょう。

**Repository パターンとは：**

> 「データの取得・保存」を専門に担当するクラスを作り、他のコード（画面やビジネスロジック）から分離するパターン

これにより：

- **変更に強くなる** — データ取得の方法が変わっても、Repository だけ修正すれば良い
- **再利用できる** — 複数の場所から同じ Repository を使える
- **役割が明確になる** — 各クラスが「自分の仕事」に集中できる

---

さて、ここで一歩進んで考えてみましょう。

今の `UserRepository` のコードを見てください：

```python
class UserRepository:
    def find_by_id(self, user_id):
        connection = Database.connect("mysql://...")  # ← ここ
        ...
```

MySQL から PostgreSQL に変えるとき、確かに `UserScreen` は触らなくて済みます。

でも、`UserRepository` 自体は「書き換える」必要がありますよね。

もし「書き換える」のではなく「差し替える」だけで済むようにしたいとしたら、どんな工夫ができそうですか？

（ヒント：MySQL 用と PostgreSQL 用、それぞれ別のクラスがあったら…？）
※これ以降も似たような調子で会話が続きました

 Gemini の場合Repository パターンについてですね。一緒に深掘りしていきましょう。

**Repository パターン**は、アプリケーションの「ビジネスロジック（何をするか）」と「データアクセス（どうやってデータを保存・取得するか）」を切り離すためのデザインパターンです。

分かりやすい例えとして、**図書館の司書（Librarian）** 📚 を想像してみてください。

* **あなた（ビジネスロジック）** は、「『桃太郎』の本が欲しい」と司書に頼みます。
* **司書（Repository）** は、その本が書棚にあるのか、地下倉庫にあるのか、あるいは別の図書館から取り寄せる必要があるのかを知っています。
* あなたは、**本がどこにどうやって保管されているかを知る必要はありません。** ただ本を受け取るだけです。

ソフトウェア開発において、このパターンを使うことで、データベースの種類（SQL、NoSQL、外部APIなど）が変わっても、ビジネスロジック側のコードを変更せずに済むようになります。

まずは、どのあたりから詳しく見ていきたいですか？

1. **導入するメリット**: なぜ直接データベースにアクセスするコードを書いてはいけないのか？テストのしやすさや保守性について知りたい。
2. **実装の構造**: インターフェースとクラスを使って、実際にコード上でどう表現するのか（Java, C#, TypeScriptなどの例）を知りたい。
3. **Unit of Work との関係**: しばしば一緒に語られる「Unit of Work パターン」との違いや組み合わせについて知りたい。
導入するメリットと、 TypeScript を用いた時の実際の構造が知りたい
メリットと、TypeScript での実装イメージですね。この2つをセットで理解すると、「なぜわざわざこんな書き方をするのか」がストンと腹に落ちるはずです。

まずはメリットから整理しましょう。

### 1. 導入するメリット（なぜ使うのか？）

Repository パターンを使う最大の理由は **「責任の分離」** です。具体的には以下の2点が大きなメリットになります。

- **🧪 テストが圧倒的に楽になる (Testability)**
    
    - 本物のデータベースを使ってテストするのは大変です（データの準備や後始末が必要）。
        
    - Repository パターンを使えば、「本物のデータベース」の代わりに「メモリ上の偽データ（モック）」を使う実装に簡単に差し替えることができます。
        
- **🛠️ 変更に強くなる (Maintainability)**
    
    - 例えば、将来「MySQL から Firestore に移行したい」となった場合、ビジネスロジック（注文処理など）のコードは一切触らず、Repository の中身（データの取り出し方）だけを書き換えれば済みます。
        

---

### 2. TypeScript による実際の構造

では、これを TypeScript でどう書くか見てみましょう。

ポイントは 「インターフェース (Interface)」 と 「実装 (Implementation)」 を分けることです。

#### ステップ 1: 「契約書」を作る (Interface)

まず、「どんな操作ができるか」だけを定義します。ここでは「中身（どうやって取るか）」は書きません。これがビジネスロジックとデータベースの間の「契約書」になります。

```typescript
// 1. まずは扱うデータ（Entity）の型定義
export type User = {
  id: string;
  name: string;
  email: string;
};

// 2. Repository のインターフェース（契約書）
// 「具体的にどうDBに繋ぐかは知らないけど、これらのメソッドは必ず持っていてね」という定義
export interface IUserRepository {
  findById(id: string): Promise<User | null>;
  save(user: User): Promise<void>;
}
```

#### ステップ 2: 「実作業者」を作る (Concrete Class)

次に、その契約書に従って、実際にデータベースを操作するクラスを作ります。

```typescript
import { IUserRepository, User } from './types'; // 上記の定義をインポート
// 実際のDBライブラリ（例: PrismaやTypeORMなど）を想定
import { db } from './infrastructure/db'; 

// 3. インターフェースを実装するクラス（実作業者）
export class UserRepository implements IUserRepository {
  
  // インターフェースで定義された findById を必ず実装しないとエラーになる
  async findById(id: string): Promise<User | null> {
    // ここで初めて SQL や DB固有の処理を書く
    const userRecord = await db.users.findUnique({ where: { id } });
    return userRecord; // ビジネスロジックが扱いやすい形（User型）で返す
  }

  async save(user: User): Promise<void> {
    await db.users.create({ data: user });
  }
}
```

---

ここまでの構造で、**インターフェース（`IUserRepository`）** と **実装クラス（`UserRepository`）** が分かれました。

ここで一つ質問させてください。

もしあなたが「ビジネスロジック（例：ユーザー登録機能）」を書く担当だとしたら、上記の **`IUserRepository`（インターフェース）** と **`UserRepository`（実装クラス）**、コードの中ではどちらの型を使って変数宣言をするのが「変更に強い」書き方だと思いますか？
インターフェースだと思います
大正解です！🎯 その通りです。

**インターフェース (`IUserRepository`)** を型として使うのがポイントです。

これを専門用語で **「依存性の注入 (Dependency Injection: DI)」** と言ったりしますが、難しく考える必要はありません。

実際のビジネスロジック（例：`UserService`）がどうなるかを見ると、なぜインターフェースを選んだのかがさらによく分かります。

TypeScript

```
import { IUserRepository } from './types'; // インターフェースだけを知っている

class UserService {
  // 这里的ポイント！
  // 具体的なクラス (UserRepository) ではなく、
  // インターフェース (IUserRepository) をコンストラクタで受け取る
  constructor(private userRepo: IUserRepository) {}

  async register(name: string, email: string) {
    // ID生成などのロジック...
    const newUser = { id: crypto.randomUUID(), name, email };

    // userRepoが本当は MySQL なのか Firestore なのかは気にしない
    await this.userRepo.save(newUser);
    console.log('登録完了！');
  }
}
```

このように書くことで、`UserService` は「データの保存場所（DBの詳細）」について何も知らなくて済みます。これが「疎結合（Loose Coupling）」な状態です。

---

さて、ここで冒頭のメリットの話に戻ります。「テストが楽になる」という点です。

`UserService` がインターフェースにしか依存していないことを利用すると、**テストの時に「偽物のデータベース」を簡単に渡せる**ようになります。

次は、この仕組みを使って **「テスト用の偽Repository（モック）」** をどう作るか見てみたいですか？ それとも、本番でどうやって **「本物のRepository」** を渡すのか（DIの仕組み）が気になりますか？
※Repository パターン自体の説明は終わった様子だったので、会話はここまでにしました

 小まとめ
ChatGPT は、選択肢で素早く状況を把握し、簡潔で要点を押さえた説明で効率的に進行。クイズ形式の確認を挟みながら、学習のペースを速く保ちます。

Claude は、複数の質問で現状を深く理解し、思考を促す質問で学習者を導きます。具体例を多用し、学習者の思考プロセスを尊重する姿勢が特徴的です。

Gemini は、比喩や絵文字を使って親しみやすく説明し、学習の方向性をユーザーに委ねます。専門用語を避け、わかりやすさを重視したアプローチです。

 戦国時代について次に、ソフトウェア関係以外の領域についても気になったので、歴史科目についても検証してみました。

（私が大学時代、歴史学を専攻していたので精度も測りやすいという事情もあります笑）
今度は高校生になったつもりで、センター試験（共通テスト）の日本史対策として

「センター試験で日本史を受験するので、戦国時代近辺について教えてください」と各モデルに伝えました。

 ChatGPT の場合了解！まずサクッと確認だけさせてください。  
あなたはいま **高校何年生**（または既卒）で、センター（共通テスト）日本史は **何点くらいを目標**にしてますか？（だいたいでOK）

---

戦国時代「近辺」って範囲が広いので、センター対策としては **まず地図を頭に作る**のが一番効きます。今日はここからいこう。

## まずは戦国時代近辺の“骨格”3つ

センターは細かい用語より、**流れ・因果・並び替え**が出やすいです。

### ① 室町後期 → 戦国へ（きっかけ）

- 室町幕府の力が弱る
    
- 有力守護・大名が自立していく
    
- 全国が「下からの実力」で動く感じになる
    

ここで超重要なワードが **「応仁の乱」**（戦国の入口として扱われがち）。

### ② 戦国の特徴（何が“新しい”の？）

- 大名が領国をまとめる（法や検地など）
    
- 家臣団・城下町・商業が発達
    
- 宗教勢力や自治的な勢力（一揆など）も絡む
    

### ③ 統一へ（織田→豊臣→徳川の流れ）

戦国の後半は「全国統一のプロセス」を問われます。

---

## いまの理解チェック（1問だけ）

戦国時代のはじまりの“きっかけ”としてよく扱われる大事件は何でしたか？（漢字でなくてもOK）
高校3年生です。90点を取りたいです。
応仁の乱
OK、高3で90点狙いなら、戦国「近辺」は **並び替え・因果・用語のセット**まで固めると伸びます。応仁の乱もバッチリ。

じゃあ次は、戦国〜統一を「骨格の年表」にして覚えやすくしよう。まずは最重要の3人から。

## 戦国〜統一の“主役3人”

センター（共通テスト）で特に狙われやすいのは  
**織田信長 → 豊臣秀吉 → 徳川家康**  
の順番と、それぞれの「代表政策セット」。

### まず信長のセット（超頻出）

- 楽市・楽座
    
- 比叡山焼き討ち（宗教勢力との対立）
    
- 長篠の戦い（鉄砲のイメージ）
    

（※細部はあとで整えるから、今は“セット”でOK）

---

## 1問だけ（ここがスタート）

**信長・秀吉・家康のうち、「楽市・楽座」をやったのは誰？**
信長
いいね、**楽市・楽座＝信長**は鉄板！

次は **秀吉の“2大セット”**を押さえると一気に点が安定します。

- 土地を把握して年貢の基準をそろえる → **検地**
    
- 武器を取り上げて一揆を防ぐ → **刀狩**  
    （この2つで **兵農分離**の流れにもつながる）
    

では1問だけ👇  
**「検地」と「刀狩」を行ったのは、信長・秀吉・家康のうち誰？**
※質問に対する答えが分かりやすすぎて、学習としてはあまり使えなさそう？な気配を感じたので会話をここで切り上げました

 Claude の場合センター試験（現在は共通テスト）の日本史対策ですね！戦国時代は政治史・文化史ともに出題頻度が高い重要な時代です。

まず、あなたの現在の理解度を教えてもらえますか？

**いくつか確認させてください：**

1. **戦国時代の「始まり」と「終わり」**について、どのような出来事を区切りとして習いましたか？
    
2. 戦国時代で特に**苦手だと感じる分野**はありますか？
    
    - 戦国大名と分国法
    - 織田信長の政策
    - 豊臣秀吉の天下統一事業
    - 文化史（桃山文化など）
    - その他
3. **用語の暗記**と**流れの理解**、どちらにより困っていますか？
    

---

これを教えてもらえると、あなたに合った形で一緒に整理していけます。

もし「全体的にざっと復習したい」ということであれば、試験で特に問われやすいポイントを中心に、時代の流れを一緒に確認していきましょう。どちらがいいですか？
応仁の乱から関ヶ原の戦いまで
文化史
流れの理解
なるほど、**文化史の流れの理解**ですね。文化史は暗記項目が多く感じますが、実は政治の動きと連動させると整理しやすくなります。

---

## まず確認させてください

この時代（応仁の乱〜関ヶ原）の文化史で、**すでに知っている文化の名前**はありますか？

例えば「○○文化」という名前や、その時代の有名な人物・建物など、なんでも構いません。

---

その上で、一つ考えてみてほしい質問があります：

> **「文化」はなぜ時代によって変わるのでしょうか？**  
> 言い換えると、ある時代に特定の文化が栄える「条件」って何だと思いますか？

ヒント：誰がお金を出すか、誰が力を持っているか、という視点で考えてみてください。

---

この視点が持てると、戦国〜安土桃山の文化史は**「権力者の変化」**という一本の軸で整理できるようになります。まずはあなたの考えを聞かせてください！
安土桃山文化
権力者によって好きなものが変わるから？
おお、その通りです！とても良い視点ですね。

**権力者が変われば、文化も変わる**——これが文化史を理解する最大のカギです。

---

## では、次のステップへ

この時代（応仁の乱〜関ヶ原）には、実は**2つの文化**があります。

|文化名|時期|
|---|---|
|**東山文化**|応仁の乱の頃（室町後期）|
|**安土桃山文化**|信長・秀吉の時代|

あなたが挙げた安土桃山文化は後半ですね。

---

## ここで考えてみてください

この2つの文化の「権力者」はそれぞれ誰でしょう？

- **東山文化**の頃の権力者 → ？
- **安土桃山文化**の頃の権力者 → ？

そして、その2人（または2グループ）には**どんな違い**があると思いますか？

ヒント：

- 身分や立場
- お金の出どころ
- 価値観や好み

この違いが分かると、「なぜ東山文化と安土桃山文化は雰囲気が全然違うのか」が見えてきます！
東山文化は分かりません... 安土桃山文化は、信長と秀吉
信長や秀吉は戦国大名で、派手なものが好きなイメージです
素晴らしい！安土桃山文化の説明、完璧です。「派手なもの好き」というイメージ、まさにその通りです。

---

## 東山文化の権力者

東山文化を代表するのは**足利義政**（室町幕府8代将軍）です。

「東山」という名前は、義政が京都の**東山**に山荘（後の銀閣寺）を建てたことに由来します。

---

## さて、ここで比較してみましょう

||東山文化|安土桃山文化|
|---|---|---|
|権力者|足利義政（将軍）|信長・秀吉（戦国大名）|
|雰囲気|？|派手・豪華|

**足利義政**について、何か知っていることはありますか？

もし分からなければ、一つヒントを出します：

> 義政は将軍なのに政治に関心がなく、**応仁の乱の原因の一つ**を作った人物です。乱の最中も関係なく東山で文化活動に没頭していました。

このエピソードから、義政が好んだ文化は「派手」だったと思いますか？それとも別の雰囲気だったと思いますか？
※これ以降も似たような調子で会話が続きました

 Gemini の場合センター試験（現・共通テスト）での日本史受験、応援しています。この時代は、単なる武将の名前よりも、**「支配の仕組み（土地制度など）」**や**「外交・貿易の変化」**が正誤問題でよく狙われます。

まずは効率よく点数に結びつけるために、どのテーマから整理していきましょうか？

1. 戦国大名の支配構造
    
    （下克上、分国法、寄親・寄子制、貫高制など、制度面の頻出用語）
    
2. 統一政権への歩み
    
    （織田信長と豊臣秀吉の政策の違い、検地・刀狩りの意義）
    
3. 対外関係と文化
    
    （鉄砲・キリスト教の伝来、南蛮貿易、この時期の都市や一揆）
    

苦手な分野や、確認したい番号を教えてください。
3
南蛮貿易と文化ですね！この分野は「誰が・いつ・何を」の組み合わせ問題が本当によく出ます。特に**鉄砲**と**キリスト教**の伝来は、戦国時代の流れを大きく変えた重要なポイントです。

まずは基本の「入口」から確認しましょう。

1543年、種子島に漂着した船に乗っていた商人が**鉄砲**を伝えました。この時、彼らはどこの国の商人だったか覚えていますか？（ヒント：スペインではありません）
イギリス？
惜しい！イギリス（やオランダ）が日本に来るのは、もう少し後の時代（1600年のリーフデ号漂着など）なんです。

センター試験（共通テスト）では、この**「来る順番」**と**「国」**のひっかけ問題がよく出ます。整理しましょう。

1543年に鉄砲を伝えたのは、スペインのお隣で**「ポ」**から始まる国です。

カステラ、カルタ、コンペイトウなどの言葉も、この国から伝わりました。

さて、どこの国か分かりますか？
ポルトガル
正解です！鉄砲を伝えたのは**ポルトガル**ですね。

ここから、ポルトガルやスペインとの**南蛮貿易**が本格化します。この貿易は、銀を輸出して、中国産の生糸や鉄砲・火薬を輸入していた点がポイントです。

さて、鉄砲（1543年）の次は**キリスト教**（1549年）です。

この肖像画の人物、1549年に鹿児島に来航して日本にキリスト教を伝えた宣教師の名前はなんでしょう？（この人物が所属していた「会」の名前も言えると完璧です！）
ザビエル
正解です、**フランシスコ・ザビエル**ですね！

もう一つ、共通テストレベルで絶対に落とせないのが、彼が所属していた**カトリックの修道会**の名前です。

イグナティウス・ロヨラらとともに創設された、この「〇〇〇会」の名前はわかりますか？
分かりません...
大丈夫ですよ、世界史の知識も混ざってくるので少しややこしいですよね。

正解は **「イエズス会」** です。

ザビエルたちは、「宗教改革」に対抗してカトリック勢力を立て直そうと結成されたこの会の一員として日本に来ました。

---

では、ここから日本国内の動きに話を広げましょう。

ザビエルたちが伝えたキリスト教は、九州の大名たちに歓迎されました。でも、大名たちがキリスト教を受け入れたのは、単に信仰心だけが理由ではありませんでした。

宣教師と仲良くすることで得られる、**「戦国時代を生き抜くためのメリット」**があったからです。

それは一体何だったと思いますか？（ヒント：さっき話に出た「輸入品」に関係があります！）
※これ以降も似たような調子で会話が続きました

 小まとめ戦国時代の学習においても、3つのモデルは異なるアプローチを見せました。

ChatGPT は、年齢や目標点数を確認し、試験対策を意識した効率的な進行。「骨格」や「セット」で情報を整理し、クイズ形式で要点を押さえます。ただし、そのクイズの難易度が低い（すぐ上に答えが書いてある）のが気になりました。

Claude は、理解度を確認し、概念的な理解を重視。「文化はなぜ変わるのか？」という問いで思考を促し、権力者と文化の関係性など、深い理解を目指します。

Gemini は、テーマ選択から始め、「誰が・いつ・何を」の組み合わせ問題に焦点。ヒントを段階的に出しながら、親しみやすい表現でクイズ中心に学習を進めます。

 それぞれのモデルの特徴以下に、改めて各モデルの特徴を整理したものを記載します。

強みや弱みに関して、大体以下のような傾向があると考えられます。

 ChatGPT の学習モード強み
ソクラテス式問答法に基づいた体系的なアプローチ
段階的なヒント提供
ユーザーの思考を促す質問
学習のペースが速く、要点を素早く押さえられる
試験対策を意識した効率的な進行
弱み
複雑な概念の説明がやや簡潔すぎる場合がある
長文での詳細な説明は Claude に劣る
ユーザーの深い思考を促すよりも、正解を導くことに重点が置かれる
ヒントがやや直接的すぎる場合がある
適していると考えられる学習シーン
基礎概念の理解を深めたいとき
効率的に要点を押さえたいとき
試験対策など、明確な目標があるとき

 Claude の学習モード強み
詳細で丁寧な説明
概念間の関連性を明確に説明
長文コンテキストの理解が優れている
個別指導の学習塾のような、学習者に寄り添う姿勢
ユーザーの思考プロセスを尊重し、深い理解を促す
弱み
自分で考える前に答えに近い情報を提示する場合がある
進行がやや遅く感じられる場合がある
適している学習シーン
理論的な背景を知りたいとき
詳細な説明が必要なとき
思考を整理しながら学びたいとき

 Gemini の学習モード強み
視覚的な説明やコード例の生成が得意
実践的なアプローチ
専門的な考えや用語が少ないため、取っ掛かりとして最も向いている
親しみやすく、学習のハードルが低い
弱み
抽象的な概念の説明がやや弱い
対話の流れがやや機械的
深い理解を促すよりも、情報を提供することに重点が置かれる
適している学習シーン
実践的な例を見ながら学びたいとき
コードや図表を活用した学習
ざっくりと概念を理解したいとき（その分野の初心者）

 まとめ3つの AI モデルの学習モードを実際の会話ログで比較した結果、それぞれに異なる強みがあることがわかりました。

効率的に要点を押さえたい → ChatGPT

深く理解し、思考を整理したい → Claude

初心者で、取っ掛かりが欲しい → Gemini
この特徴を踏まえて適切なモデルを選択することで、より効果的な学習体験が得られると思います。

また、学習対象の領域に応じてモデル選択するのも良いと思います。

（今回の歴史科目のように、理解を深めたいなら Claude を利用する、など）

複数のモデルを組み合わせて使用することで、それぞれの強みを活かした学習の可能性が見えてきたんじゃないでしょうか？

 注意事項学習モードとは言え、ハルシネーション発生の問題は存在します。

あくまでも概念理解に留めておき、100%鵜呑みにせず、学んだことを整理して別途ファクトチェックした方が安心です！
モデル名	質問スタイル	説明スタイル	学習アプローチ	適している学習シーン
ChatGPT	選択肢（A-D）で素早く状況把握	簡潔で要点を押さえた説明	クイズ形式で効率的に進行	効率的に要点を押さえたいとき
Claude	複数質問で現状を深く理解	詳細で丁寧な説明	思考を促す質問で深い理解を促進	深く理解し、思考を整理したいとき
Gemini	選択肢で学習方向を委ねる	比喩や絵文字で親しみやすく	ステップバイステップで実践的	初心者で、取っ掛かりが欲しいとき
はじめに

TL;DR

各モデルの学習モードの設定方法と、今回の記事で設定したモデルについて

ChatGPT

Claude の学習モード

Gemini の学習モード

実際に試してみた

Repository パターンについて

ChatGPT の場合

Claude の場合

Gemini の場合

小まとめ

戦国時代について

ChatGPT の場合

Claude の場合

Gemini の場合

小まとめ

それぞれのモデルの特徴

ChatGPT の学習モード

Claude の学習モード

Gemini の学習モード

まとめ

注意事項

Discussion
