ClaudeAIの「拡張思考モード」について探ってみた

Zennでブログを書くのは初めてなので、はじめまして。
株式会社カンリーでエンジニアをしている和田です。

カンリーでは「AI使っていこうよ！‥いや、使えよ！！」的なムーブが起こっているのでAI関連の記事を書いてみます。今回、私が書く記事は最近仲良くしているAnthropic社が開発した「Claude」についてです。

技術的な壁打ちから、マネジメントに関する相談、ちょっとした話し相手などなど‥仲良くしてもらっています。

それでは、いってみましょー！！

ClaudeAIとは

ClaudeはAnthropicによって開発された大規模言語モデル（LLM）で、ChatGPTと同様に自然な会話能力と複雑なタスクを処理する能力を持っています。2023年に一般公開され、2025年2月にはClaude 3.7 Sonnetがリリースされました。

現在のフラッグシップモデルであるClaude 3.7 Sonnetは、推論能力、複雑な指示への対応、多言語サポートなどの面に強く、また、「思考モード(extended thinking mode)」を活用することで、より深い思考プロセスを経た回答をしてくれるようになりました！

ちなみに‥
思考モードはClaude 3.7 Sonnetの特別な機能で且つProアカウントのみで利用可能です！

そう、貢げば私のためにめっちゃ考えてくれます！！

標準モードと思考モードをそれぞれ使ってみる

それぞれのモードでの比較をするために、共通のお題を与えなければなりません。
今回のお題として与えたものがこちら！

GoでREST APIをGinフレームワークを使って構築し、入力バリデーションとエラーハンドリングを適切に設計・実装してください

全文を載せることが難しいため、標準モードと思考モードとで出力されたコードの違いを抜粋しながら見ていきます。

パスワードの出力制御

標準モード	思考モード
Password に json:"-" がないためレスポンスに含まれる	json:"-" により出力抑制（セキュリティ強化）

標準モード

type User struct {
  Name     string `json:"name" binding:"required,min=3,max=50"`
  Email    string `json:"email" binding:"required,email"`
  Age      int    `json:"age" binding:"required,gte=18,lte=120"`
  Password string `json:"password" binding:"required,min=8"`
}

思考モード

type User struct {
  ID       uint   `json:"id"`
  Name     string `json:"name" binding:"required,min=3,max=50"`
  Email    string `json:"email" binding:"required,email"`
  Age      int    `json:"age" binding:"required,gte=18,lte=120"`
  Password string `json:"password" binding:"required,min=8" json:"-"`
}

レスポンスに出力制限がかけられ、よりセキュアな設計となっています。

バリデーションエラー処理関数

標準モード	思考モード
ValidationErrorHandler を使用	HandleValidationErrors を使用

標準モード

type ErrorResponse struct {
  Field   string `json:"field"`
  Message string `json:"message"`
}

func ValidationErrorHandler(err error) []ErrorResponse {
  var errors []ErrorResponse
  ...
}

思考モード

type ErrorResponse struct {
  Error       string            `json:"error"`
  Message     string            `json:"message"`
  FieldErrors []FieldError      `json:"field_errors,omitempty"`
  Details     map[string]string `json:"details,omitempty"`
}

type FieldError struct {
  Field   string `json:"field"`
  Message string `json:"message"`
}

func HandleValidationErrors(err error) []FieldError {
  var errors []FieldError
  ...
}

呼び出し元や詳細メッセージを省略しているので分かりづらい部分はありつつ‥
標準モードではErrorResponseを1件ずつ返す設計になっている一方で、思考モードではErrorResponseの中に構造体として定義した[]FieldErrorを持たせて複数のフィールドに関する詳細エラーをひとつのレスポンスにまとめて返しています。
これにより、APIレスポンスが構造化されて理解しやすくなり、クライアントでの扱いがしやすくなります。

ミドルウェアの違い

標準モード	思考モード
簡易的に c.Errors.JSON() を返す	明確に ApiError を解析し適切なレスポンスを生成

標準モード

router.Use(func(c *gin.Context) {
  c.Next()
  if len(c.Errors) > 0 {
    c.JSON(c.Writer.Status(), gin.H{
    "errors": c.Errors.JSON(),
    })
  }
})

思考モード

router.Use(RecoveryMiddleware())
router.Use(ErrorHandlerMiddleware())

func ErrorHandlerMiddleware() gin.HandlerFunc {
  return func(c *gin.Context) {
    c.Next()
    if len(c.Errors) > 0 {
      err := c.Errors.Last().Err
      // ApiError チェックとハンドリング
      ...
      c.JSON(statusCode, response)
    }
  }
}

func RecoveryMiddleware() gin.HandlerFunc {
  return func(c *gin.Context) {
    defer func() {
      if r := recover(); r != nil {
        log.Printf("Panic recovered: %v", r)
        c.JSON(http.StatusInternalServerError, ErrorResponse{
          Error:   "INTERNAL_ERROR",
          Message: "An unexpected error occurred",
        })
        c.Abort()
      }
    }()
    c.Next()
  }
}

標準モードでは簡易エラーハンドルに対し、思考モードでは2つのミドルウェアで堅牢な例外処理を実現しようとしています。また、標準モードの場合ではカスタムエラー構造を持たずGinのc.Error()にそのまま渡す設計となっていますが、思考モードではApiError型を定義し、HTTPステータスにマッピング可能な設計となりました。

その他の主な違い

これ以外にもパニックを考慮し対応していたり、エラーの詳細情報を含めたり、多様なケースを想定し複数エンドポイントを設計したりと、人が考えると同等、或いはそれ以上に思考し回答を出力してくれました。

また、思考モードでは標準モードとは対象的に回答前に以下のような詳細な思考プロセスが示されます！

この課題に取り組むには、以下の要素を考慮する必要があります：

1. GoでREST APIを構築する - Ginフレームワークを使用
2. 入力バリデーションの実装
3. エラーハンドリングの設計

まず、全体的なアプローチを考えます：

**プロジェクト構造の設計**
REST APIでは、関心の分離を維持することが重要です。一般的にはレイヤー分けを行います：
- ハンドラー（コントローラー）層：HTTPリクエスト/レスポンスの処理
- サービス層：ビジネスロジック
- リポジトリ層：データアクセス

しかし、課題の主眼は入力バリデーションとエラーハンドリングなので、完全な構造よりもこれらに焦点を当てます。

みたいな感じで独り言をいいながら考えてくれます！

どんなときに役立つのか

今回はAPIの実装を試してみましたが、この他、システム開発においては以下のようなシーンでも効果を発揮します！！

1. 複雑なアルゴリズムの実装
   複数のステップや条件分岐を含むアルゴリズムを設計する場合、思考モードではアプローチの検討から実装までの流れを明示的に示します。

2. アーキテクチャ設計
   システム設計やアーキテクチャの検討において、思考モードは複数の選択肢とそのトレードオフを詳細に分析します。

3. デバッグと問題解決
   複雑なバグの解析では、思考モードによる段階的な問題分解と仮説検証が有効です。

4. パフォーマンス最適化
   パフォーマンス問題の分析と最適化では、思考モードは複数のアプローチを比較検討し、最適な解決策を見つけ出します。

また、システム開発以外の分野でも拡張思考モードは大きな効果を発揮すると評価されており、例えば数学の証明であったり、データの解析や傾向分析、或いは多角的な検討が必要な意思決定のような場面や、はたまた倫理的なジレンマや哲学的な問いに対しても深く思考し回答を出してくれます。

標準モードと比較し拡張思考モードの場合、結果が出力されるまで数分程度要する場合もありますが、それでも人間があーだこーだ考えるよりも圧倒的に速い速度で且つ網羅的に思考し回答を出してくれます。

まとめ

とまあ、ここまで「拡張思考モードすごいんだぜ！」っていうのを推してきましたが、まだまだ課題はあって事実の正確性、いわゆる「ハルシネーション」の問題は依然として存在します！また、常に最新の情報だとは限らず、引き続き、検索エンジンとの併用が必要だったり、出力された回答に対し人間がレビューをしなければなりません。

MCPとの連携や、最近ではA2Aの発表などもありAIがアシスタントやナビゲートではなくドライバーとして活躍すると言われるような時代になってきましたが、私は自らの頭で考えることをやめずAIと付き合っていきたいと思っています。