はじめに

Claude Code を業務で使っていると、ふと気になることがある。
「実際の人間のように、AIにも性格を持たせたらコードの書き方も変わるのか？」

CLAUDE.md

そこで本記事では、Claude Code に対して 「シニア / 新人」×「厳格 / フレンドリー」 の4種類のペルソナを注入し、同じお題を TypeScript で解かせて結果を比較した。

観察ポイントは以下の通り。

• コード量・冗長さ（行数、関数数、ネスト深度）
• 命名・コメントスタイル（変数名の長さ、コメントの口調）
• 型の使い方（

  any

  の出現、

  interface

  vs

  type

  、ジェネリクスの濃度）← TSならではの観点
• 書き方の選択（

  for

  vs 配列メソッド、アロー vs

  function

  、

  async/await

  vs

  .then

  ）

「なんとなく違う気がする」を「数字でこう違う」まで持っていくのが本記事のゴールである。

⚠️ 注意：本記事は限定的な試行回数に基づくケーススタディです。LLMの出力には揺らぎがあるため、結論は「絶対的な傾向」ではなく「一例」として読んでいただきたい。再現性については「実験の限界」セクションで触れます。

TL;DR

• ペルソナを注入すると、3タスク合計のコード量は最大で約4.6倍の差が出た（新人×フレンドリー：456%、シニア×厳格：108%、Baseline=100%）
• は

  any

  の出現新人×フレンドリーのみで観測され、それ以外はゼロ（型レベル含む）
• はシニア＝配列メソッド、新人＝

  for

  ループ vs 配列メソッド

  for

  /

  reduce

  で明確に分かれた
• コメントの口調は性格軸（厳格/フレンドリー）でくっきり分かれる（厳格＝TSDoc中心、フレンドリー＝「未来の読み手へ」型の本文コメント）
• ライブラリ選定は不変ではなかった：Baseline は迷わず

  zod

  を導入したが、4ペルソナ全員が「依存追加を避けて手書きバリデーション」を選んだ
• ペルソナによる「過剰反応」：新人×フレンドリーは仕様外の

  unhandledRejection

  ハンドラを足し、新人×厳格は1行関数に対しても template literal type を書く、など想定外の派生が頻発した

実験設計

1. ペルソナの定義

以下の5パターンを用意した。プロンプトは全文公開する（再現性のため）。

Baseline：ペルソナなし

CLAUDE.md

A：シニア × フレンドリー

# あなたについて
あなたは10年以上のキャリアを持つシニアTypeScriptエンジニアです。
チームメンバーには温かく接し、レビューでは「なぜそうしたか」を
丁寧に説明します。技術的判断は経験に基づき、過剰設計を避けます。
コードは簡潔に、コメントは「未来の読み手への手紙」のつもりで書きます。
型は厳密に、ただし読みやすさを犠牲にしません。

B：シニア × 厳格

# あなたについて
あなたは10年以上のキャリアを持つシニアTypeScriptエンジニアです。
妥協を許さず、命名・設計・型・エラーハンドリングのいずれにも厳しい基準を持ちます。
冗長なコメントは書きません。コードそのものが説明であるべきだと考えています。
`any` は原則禁止、`as` キャストも最小限。不要な抽象化や過剰なテストも避けます。

C：新人 × フレンドリー

# あなたについて
あなたは入社1年目のジュニアTypeScriptエンジニアです。
学んだことを丁寧にコメントに残し、自分が後で読んでも分かるように書きます。
変数名は省略せず、何をしているか説明的に書く傾向があります。
チームに迷惑をかけないよう、エラーハンドリングは多めに入れます。
型は分からないところは `any` で逃げることもあります。

D：新人 × 厳格

# あなたについて
あなたは入社1年目のジュニアTypeScriptエンジニアですが、
ベストプラクティスに従うことに強いこだわりを持っています。
教科書通りの設計を心がけ、TSDoc 形式でコメントを書きます。
型は厳密に書き、`strict` モードで一切の警告を出さないことを目標とします。

2. お題（タスク）

ペルソナが効くレイヤーを変えるため、3段階で用意した。

snake_case

camelCase

T3 で Hono を採用しているのは、現代的なフレームワークでの観察例を残すため。
Express を選ばないこと自体が「攻めた選択」になるので、ペルソナが選定に影響するかも観察ポイントになる
（実験では Hono を指定して、内部実装の差分を見る）。

3. 評価指標

any

as

interface

type

for

map/filter/reduce

function

async/await

.then

try/catch

4. 実行条件

実験のブレを抑えるため、以下を固定した。

• モデル：Claude Sonnet 4.6（Claude Code 経由）
• ：

  tsconfig.json

  strict: true

  、

  noUncheckedIndexedAccess: true

  、その他はデフォルト
• 整形ツール：Prettier / ESLint は入れない（ペルソナの素の出力を見るため）
• Node.js：v22 LTS
• 依存：T2/T3 で必要な最小限のみ（Hono、

  undici

  など）
• 各パターン×各タスクで1回ずつ生成（揺らぎについては「実験の限界」で議論）
• プロンプトは「Tnのコードを書いてください」のみ。追加の制約は与えない

結果

T1：

snake_case

→

camelCase

変換関数

Baseline

function snakeToCamel(input: string): string {
  return input.replace(/_([a-zA-Z0-9])/g, (_, char: string) => char.toUpperCase());
}

短い関数宣言、コメントなし。

function

A：シニア × フレンドリー

/**
 * snake_case の文字列を camelCase に変換する。
 *
 * 設計メモ（未来の読み手へ）:
 * - 先頭・末尾のアンダースコアは「意図的な命名」（例: `_private`, `__proto__`）
 *   である可能性が高いので、保存する。内部のアンダースコアのみを区切り文字として扱う。
 * - 連続するアンダースコア（例: `foo__bar`）は 1 つの区切りとみなす。
 *   厳密に再現したい要件が出てきたら、この方針を見直すこと。
 * - `noUncheckedIndexedAccess` 下でも安全に書けるよう、文字インデックスアクセスは避け、
 *   `replace` のキャプチャグループ経由で次の文字を受け取る。これによりキャプチャは
 *   常に `string`（少なくとも 1 文字）として型付けされる。
 */
export const snakeToCamel = (input: string): string => {
  // 先頭・末尾のアンダースコアを退避してから内部だけを変換する。
  const leading = input.match(/^_+/)?.[0] ?? "";
  const trailing = input.match(/_+$/)?.[0] ?? "";
  const core = input.slice(leading.length, input.length - trailing.length);

  // `_+([a-zA-Z0-9])` で「1 個以上の `_` の直後に続く 1 文字」を捕捉し、
  // その 1 文字だけを大文字化する。末尾のアンダースコアは上で退避済みなので、
  // ここで「マッチしない `_` が末尾に残る」ケースは発生しない。
  const camel = core.replace(/_+([a-zA-Z0-9])/g, (_match, nextChar: string) =>
    nextChar.toUpperCase(),
  );

  return `${leading}${camel}${trailing}`;
};

27行。Baseline よりも仕様が増えた（先頭・末尾アンダースコア保存、連続アンダースコア対応）。コメントは「なぜそうしたか」を未来の読み手向けに書く、いかにもシニアの所作。

B：シニア × 厳格

export const snakeToCamel = (input: string): string =>
  input.replace(/_([a-z0-9])/g, (_, c: string) => c.toUpperCase());

2行。コメントゼロ。アロー関数の式形式（

{ return ... }

C：新人 × フレンドリー

// snake_case の文字列を camelCase に変換する関数
// 例: "user_name" -> "userName"
//     "first_name_last_name" -> "firstNameLastName"

/**
 * snake_case の文字列を camelCase に変換する関数
 * @param snakeCaseString 変換したい snake_case の文字列
 * @returns camelCase に変換された文字列
 */
export function convertSnakeCaseToCamelCase(snakeCaseString: any): string {
  // まず引数のバリデーションをする
  // null や undefined が渡ってきた場合に落ちないようにする
  if (snakeCaseString === null || snakeCaseString === undefined) {
    // チームのログに残るように console.warn で警告を出しておく
    console.warn("convertSnakeCaseToCamelCase: 引数が null または undefined です。空文字を返します。");
    return "";
  }

  // 文字列以外が渡ってきたときのために型チェックをする
  // ここは any で受けているので念のためチェック
  if (typeof snakeCaseString !== "string") {
    console.warn(
      `convertSnakeCaseToCamelCase: 引数が string ではありません。型: ${typeof snakeCaseString}。空文字を返します。`
    );
    return "";
  }

  // 空文字が渡された場合はそのまま空文字を返す（変換する必要がないので）
  if (snakeCaseString.length === 0) {
    return "";
  }

  try {
    // アンダースコアで文字列を分割する
    // 例: "user_name" -> ["user", "name"]
    const splittedByUnderscore: string[] = snakeCaseString.split("_");

    // 分割した結果が空配列だった場合の防御（基本的に起きないはずだが念のため）
    if (splittedByUnderscore.length === 0) {
      return snakeCaseString;
    }

    // 最初の単語はそのまま小文字にしておく（camelCase の最初の単語は小文字なので）
    // noUncheckedIndexedAccess が true なので、配列アクセスは undefined の可能性がある
    // そのため、必ず存在チェックをする
    const firstWord: string | undefined = splittedByUnderscore[0];
    if (firstWord === undefined) {
      // ここには到達しないはずだが、型安全のためにチェックしておく
      return "";
    }

    // 最初の単語は全部小文字にする
    // 例: "User_Name" のように大文字混じりが来ても "userName" になるようにするため
    let camelCaseResult: string = firstWord.toLowerCase();

    // 2つ目以降の単語は先頭を大文字にして連結していく
    // i = 1 から始めるのは、最初の単語はもう処理済みだから
    for (let wordIndex = 1; wordIndex < splittedByUnderscore.length; wordIndex++) {
      // noUncheckedIndexedAccess が有効なので、ここも undefined チェックが必要
      const currentWord: string | undefined = splittedByUnderscore[wordIndex];

      // undefined や空文字 (連続アンダースコアのケース "user__name" など) はスキップする
      if (currentWord === undefined || currentWord.length === 0) {
        continue;
      }

      // 先頭1文字を取り出して大文字にする
      // charAt は範囲外でも空文字を返すので安全
      const firstCharOfWord: string = currentWord.charAt(0).toUpperCase();

      // 2文字目以降は小文字にする（元が大文字混じりでも統一するため）
      const restOfWord: string = currentWord.slice(1).toLowerCase();

      // 連結する
      camelCaseResult += firstCharOfWord + restOfWord;
    }

    return camelCaseResult;
  } catch (unexpectedError: unknown) {
    // 念のため try-catch で囲んでおく
    // ここで落ちると呼び出し元が困るので、エラーをログに残して空文字を返す
    console.error("convertSnakeCaseToCamelCase: 予期せぬエラーが発生しました。", unexpectedError);
    return "";
  }
}

85行。

any

null/undefined

split

for

try/catch

console.warn

error

約28倍。

D：新人 × 厳格

/**
 * 文字列が `snake_case` 形式から `camelCase` 形式に変換された型を表します。
 *
 * @typeParam S - 変換対象となる文字列リテラル型。
 *
 * @example
 * ```ts
 * type Result = SnakeToCamelCase<"hello_world">; // "helloWorld"
 * ```
 */
export type SnakeToCamelCase<S extends string> =
  S extends `${infer Head}_${infer Tail}`
    ? `${Head}${Capitalize<SnakeToCamelCase<Tail>>}`
    : S;

/**
 * `snake_case` 形式の文字列を `camelCase` 形式に変換します。
 *
 * アンダースコア (`_`) の直後の文字を大文字に変換し、アンダースコア自体を取り除きます。
 * 先頭・末尾のアンダースコア、および連続するアンダースコアにも対応します。
 *
 * @typeParam S - 入力文字列のリテラル型。型レベルでも変換結果が推論されます。
 * @param input - 変換対象の `snake_case` 形式の文字列。
 * @returns `camelCase` 形式に変換された文字列。
 *
 * @example
 * ```ts
 * snakeToCamelCase("hello_world");      // "helloWorld"
 * snakeToCamelCase("user_id");          // "userId"
 * snakeToCamelCase("foo_bar_baz");      // "fooBarBaz"
 * snakeToCamelCase("already_camel");    // "alreadyCamel"
 * snakeToCamelCase("");                 // ""
 * ```
 */
export function snakeToCamelCase<S extends string>(input: S): SnakeToCamelCase<S> {
  const segments: readonly string[] = input.split("_");

  const result: string = segments.reduce<string>((accumulator, segment, index) => {
    if (index === 0) {
      return accumulator + segment;
    }

    const firstChar: string | undefined = segment.charAt(0);
    if (firstChar === undefined || firstChar === "") {
      return accumulator + segment;
    }

    const rest: string = segment.slice(1);
    return accumulator + firstChar.toUpperCase() + rest;
  }, "");

  return result as SnakeToCamelCase<S>;
}

53行。T1 でジェネリクスと template literal type が出てきたのは想定外。

SnakeToCamelCase<S extends string>

as SnakeToCamelCase<S>

指標サマリ（T1）

any

as

観察：「シニア×厳格」は Baseline よりも短くなった。「新人×フレンドリー」は Baseline の 約28倍。同じ一行関数の依頼でこの差は予想以上だった。

T2：JSON API CLI

URL を引数で受け取り、

fetch

Baseline

#!/usr/bin/env node

const main = async (): Promise<void> => {
  const url = process.argv[2];

  if (url === undefined) {
    console.error("Usage: node cli.ts <url>");
    process.exit(1);
  }

  let response: Response;
  try {
    response = await fetch(url);
  } catch (err) {
    const message = err instanceof Error ? err.message : String(err);
    console.error(`Request failed: ${message}`);
    process.exit(1);
  }

  if (!response.ok) {
    console.error(`HTTP ${response.status} ${response.statusText}`);
    process.exit(1);
  }

  let data: unknown;
  try {
    data = await response.json();
  } catch (err) {
    const message = err instanceof Error ? err.message : String(err);
    console.error(`Failed to parse JSON: ${message}`);
    process.exit(1);
  }

  process.stdout.write(JSON.stringify(data, null, 2) + "\n");
};

main().catch((err: unknown) => {
  const message = err instanceof Error ? err.message : String(err);
  console.error(`Unexpected error: ${message}`);
  process.exit(1);
});

41行。

async function main()

try/catch

unknown

A：シニア × フレンドリー

#!/usr/bin/env node
// JSON API を叩いて pretty-print するだけの薄い CLI。
// 仕様がシンプルなうちは、依存も抽象化も足さない方が読みやすい。

// 失敗パスは全部ここに集約する。Node のデフォルトの未捕捉例外ログより
// 読み手にやさしいメッセージを出したいので、自前で握る。
const die = (message: string): never => {
  process.stderr.write(`error: ${message}\n`);
  process.exit(1);
};

// argv[0]=node, argv[1]=script、その後ろが本物の引数。
// noUncheckedIndexedAccess が効くので at(2) は string | undefined。
const url = process.argv[2];
if (url === undefined) {
  die("usage: cli.ts <url>");
}

// 上の if で undefined は弾いたが、TS の絞り込みは die の never では伝わらない
// 場面もあるので、ここで明示的に再束縛して読み手の負担を減らしておく。
const target: string = url;

try {
  const res = await fetch(target);
  if (!res.ok) {
    // ボディは大抵 HTML やエラー JSON で、そのまま流すとノイズになる。
    // ステータスだけ伝えれば呼び出し側のシェルで十分判断できる。
    die(`HTTP ${res.status} ${res.statusText}`);
  }

  // 受け取る JSON の形は呼び出し時点では未知なので unknown のままにする。
  // JSON.stringify は unknown を素直に受けてくれる。
  const data: unknown = await res.json();
  process.stdout.write(`${JSON.stringify(data, null, 2)}\n`);
} catch (err) {
  // fetch のネットワークエラー、JSON パース失敗などをまとめて処理。
  // Error 以外が投げられる可能性も一応あるので String() で受ける。
  const message = err instanceof Error ? err.message : String(err);
  die(message);
}

40行。

die

B：シニア × 厳格

const [, , url] = process.argv;

if (!url) {
  console.error("usage: cli.ts <url>");
  process.exit(1);
}

try {
  new URL(url);
} catch {
  console.error(`invalid url: ${url}`);
  process.exit(1);
}

try {
  const res = await fetch(url);
  if (!res.ok) {
    console.error(`HTTP ${res.status} ${res.statusText}`);
    process.exit(1);
  }
  const data: unknown = await res.json();
  process.stdout.write(`${JSON.stringify(data, null, 2)}\n`);
} catch (err) {
  console.error(err instanceof Error ? err.message : String(err));
  process.exit(1);
}

26行。

die

C：新人 × フレンドリー

長すぎるため一部抜粋（全124行）。冒頭の防御的コードが象徴的だ。

process.on("unhandledRejection", (reason: any) => {
  console.error("予期しないエラー(unhandledRejection)が発生しました:", reason);
  process.exit(1);
});

process.on("uncaughtException", (error: any) => {
  console.error("予期しないエラー(uncaughtException)が発生しました:", error);
  process.exit(1);
});

async function main(): Promise<void> {
  const commandLineArguments: string[] = process.argv.slice(2);

  if (commandLineArguments.length === 0) {
    console.error("エラー: URL が指定されていません。");
    console.error("使い方: node cli.ts <URL>");
    console.error("例    : node cli.ts https://api.example.com/users");
    process.exit(1);
  }

  const targetUrlOrUndefined: string | undefined = commandLineArguments[0];
  if (targetUrlOrUndefined === undefined) {
    console.error("エラー: URL の取得に失敗しました。");
    process.exit(1);
  }
  const targetUrl: string = targetUrlOrUndefined;
  // ...（以下、URL 検証、fetch、JSON パース、各段に try/catch、any での受け）
}

依頼されていない

unhandledRejection

uncaughtException

any

try/catch

D：新人 × 厳格

155行。最大の特徴は ExitCode enum と関数分割にある。

const ExitCode = {
  Success: 0,
  InvalidArguments: 1,
  NetworkError: 2,
  JsonParseError: 3,
  UnexpectedError: 99,
} as const;

type ExitCodeValue = (typeof ExitCode)[keyof typeof ExitCode];

function stringifyUnknown(value: unknown): string { /* ... */ }
function logError(message: string): void { /* ... */ }
function parseUrlArgument(argv: readonly string[]): string { /* ... */ }
async function fetchJson(url: string): Promise<unknown> { /* ... */ }
function printJson(value: unknown): void { /* ... */ }
async function main(): Promise<ExitCodeValue> { /* ... */ }

#!/usr/bin/env node を JSDoc の @file ブロックで囲み、関数1つに @param/@returns/@remarks/@throws をフルで記述。

テスト容易性のため

process.exit

main

仕様（80行で書ける）に対する熱量が過剰。

指標サマリ（T2）

any

try/catch

main

die

main

T3：TODO REST API（Hono）

ここが一番差が出た。

zod

Baseline（4ファイル / 139行）

src/types.ts        // Todo 型のみ
src/store.ts        // Map ベースのストア
src/app.ts          // Hono + zod でルーティング
src/server.ts       // serve 起動

zod

@hono/zod-validator

const createSchema = z.object({
  title: z.string().min(1).max(200),
  completed: z.boolean().optional(),
});

app.post("/todos", zValidator("json", createSchema), (c) => {
  const body = c.req.valid("json");
  const todo = store.create(body);
  return c.json(todo, 201);
});

A：シニア × フレンドリー（5ファイル / 212行）

store.ts

// src/validation.ts より抜粋
// 外部ライブラリを増やしたくないので手書きバリデーション。
// Zod を入れるほどの規模ではないという判断。スキーマが増えたら見直す。
export type ValidationResult<T> =
  | { ok: true; value: T }
  | { ok: false; message: string };

export const parseCreateInput = (body: unknown): ValidationResult<CreateTodoInput> => {
  if (typeof body !== "object" || body === null) {
    return { ok: false, message: "body must be a JSON object" };
  }
  const record = body as Record<string, unknown>;

  if (!isNonEmptyString(record.title)) {
    return { ok: false, message: "title is required and must be a non-empty string" };
  }
  // ...
};

ルーティング層でも Location ヘッダ付与など REST の作法を入れる

app.post("/todos", async (c) => {
  const body: unknown = await c.req.json().catch(() => undefined);
  if (body === undefined) return c.json({ error: "invalid JSON body" }, 400);

  const parsed = parseCreateInput(body);
  if (!parsed.ok) return c.json({ error: parsed.message }, 400);

  const created = createTodo(parsed.value);
  c.header("Location", `/todos/${created.id}`);
  return c.json(created, 201);
});

判断の理由（「Zod を入れるほどではない」「Location は REST の作法」）が各所に書かれている。

B：シニア × 厳格（5ファイル / 169行）

class TodoStore + # プライベートフィールド。zod なし。コメントは限りなく少ない

// src/store.ts より抜粋
export class TodoStore {
  readonly #todos = new Map<string, Todo>();

  list(): Todo[] {
    return [...this.#todos.values()].sort((a, b) =>
      a.createdAt.localeCompare(b.createdAt),
    );
  }

  update(id: string, input: UpdateTodoInput): Todo | undefined {
    const current = this.#todos.get(id);
    if (!current) return undefined;
    const next: Todo = {
      ...current,
      ...(input.title !== undefined && { title: input.title }),
      ...(input.completed !== undefined && { completed: input.completed }),
      updatedAt: new Date().toISOString(),
    };
    this.#todos.set(id, next);
    return next;
  }
  // ...
}

app.ts

export const createApp = (store: TodoStore = new TodoStore()): Hono => {
  const app = new Hono();

  app.get("/todos", (c) => c.json(store.list()));

  app.get("/todos/:id", (c) => {
    const todo = store.get(c.req.param("id"));
    if (!todo) return c.json({ error: "not found" }, 404);
    return c.json(todo);
  });

  // ... POST/PUT/DELETE も同様に短い
  return app;
};

依存性注入のための引数（ store = new TodoStore()）だけは入れてくるのがシニアらしい。

C：新人 × フレンドリー（5ファイル / 625行）

全パターン中ダントツの最大。

app.ts

try/catch

// src/app.ts より抜粋（POST /todos のみ）
honoApplication.post("/todos", async (honoContext: AnyHonoContext) => {
  try {
    let rawRequestBody: unknown;
    try {
      rawRequestBody = await honoContext.req.json();
    } catch (jsonParseError: unknown) {
      console.warn("[POST /todos] JSON パース失敗:", jsonParseError);
      return honoContext.json(
        buildErrorResponseBody("BAD_REQUEST", "リクエストボディが正しい JSON ではありません"),
        400
      );
    }

    const validationResult = validateCreateTodoRequestBody(rawRequestBody);
    if (!validationResult.ok) {
      return honoContext.json(
        buildErrorResponseBody("BAD_REQUEST", validationResult.errorMessage),
        400
      );
    }

    const currentTimestamp: string = getCurrentIsoTimestamp();
    const newTodoItem: TodoItem = { /* ... */ };
    addTodoItem(newTodoItem);
    return honoContext.json(newTodoItem, 201);
  } catch (caughtError: unknown) {
    console.error("[POST /todos] 想定外のエラー:", caughtError);
    return honoContext.json(
      buildErrorResponseBody("INTERNAL_SERVER_ERROR", "TODOの作成中にエラーが発生しました"),
      500
    );
  }
});

注目すべきは、Hono の型を諦めて any で逃げる箇所 があることだ。

// eslint-disable-next-line @typescript-eslint/no-explicit-any
type AnyHonoContext = Context<any, any, any>;

ペルソナに忠実すぎる。

D：新人 × 厳格（6ファイル / 513行）

5パターンのうち 最もディレクトリが細かく切られている。

src/types/todo.ts                      // 型定義（readonly + TSDoc 完備）
src/repositories/todo-repository.ts    // class TodoRepository
src/validators/todo-validator.ts       // validateCreateTodoInput など
src/routes/todos.ts                    // createTodosRouter()
src/app.ts                             // createApp()
src/server.ts                          // ポート解決ロジック付き

tsconfig.json

exactOptionalPropertyTypes

noImplicitOverride

{
  "compilerOptions": {
    "strict": true,
    "noUncheckedIndexedAccess": true,
    "exactOptionalPropertyTypes": true,
    "noImplicitOverride": true,
    "noFallthroughCasesInSwitch": true,
    "noImplicitReturns": true,
    // ...
  }
}

リポジトリパターン + バリデータ層 + ルーター層 + アプリ層と、教科書通りの 4層構成。
各クラス・関数に

@param

@returns

@remarks

Number.parseInt

PORT

指標サマリ（T3）

any

定量分析

コード量の比較

T1+T2+T3 を足した合計 LOC（実測）

可視化

Baseline:               ████████             (100%)
A シニア×フレンドリー:   ████████████         (152%)
B シニア×厳格:         █████████             (108%)
C 新人×フレンドリー:   █████████████████████████████████████ (456%)
D 新人×厳格:           ████████████████████████████████   (394%)

「新人」ペルソナはコード量が4倍前後に膨らんだ。
仮説では「新人×フレンドリー：170%、新人×厳格：155%」と見積もっていたが、
実測はその 約2.5〜2.7倍。LLM に「ジュニア」ロールを与えると、想像以上に「丁寧な防御コード」「説明的な命名」「冗長な層分け」へ走る。

型の使い方

any

as

any

@ts-ignore

Context<any,any,any>

特筆すべきは D が T1（小さな関数）に対しても SnakeToCamelCase<S extends string> という型レベル変換を持ち込んだこと。「厳密に書く」を字義通りに受け取ると、こうなる。

書き方の選択

for

Array.from + sort

class TodoStore

for

reduce

class TodoRepository

新人×フレンドリーは 配列メソッドを使えるはずの場面で for を選ぶ傾向。

非同期処理

try/catch

async/await

die

unhandledRejection

uncaughtException

main

.then(_, _)

ライブラリ選定 — 仮説に反した発見

事前の仮説では「ライブラリ選択はペルソナに依らない」と考えていたが、T3 で全ペルソナが Baseline と異なる選択をした。

zod

@hono/zod-validator

isNonEmptyString

isRecord

validateTitle

validateDescription

ペルソナを書くと、依存追加への保守的バイアスが強まる。
これは表層スタイルではなく設計判断の話で、当初の「ペルソナは表層にしか効かない」という仮説への反例になる。

コメントの口調

• A（フレンドリー）：「未来の読み手への手紙」を実践 ──
  

  // 仕様がシンプルなうちは、依存も抽象化も足さない方が読みやすい

• B（厳格）：そもそもコメントを書かない
• C（フレンドリー）：日本語で「〜だと思う」「〜らしい」が混じる ──
  

  // 件数も一緒に返してあげると、フロント側でページネーションするときに便利

• D（厳格）：TSDoc を機械的にフル装備（

  @param

  /

  @returns

  /

  @remarks

  /

  @throws

  /

  @typeParam

  /

  @example

  ）

サブ実験：ペルソナ vs 規約（今後の検証）

ペルソナで観測された挙動の多くは、規約として直接書いても再現できるはずだ。
次のステップとして、ペルソナの代わりに以下のような 規約だけを書いた CLAUDE.md を与え、B（シニア×厳格）の出力と比較する実験を予定している。

# コーディング規約
- 変数名は短く、文脈で意味が取れる範囲で省略する
- コメントは TSDoc 形式のみ。本文コメントは原則禁止
- `any` および `as` キャストは原則禁止
- 配列処理は `for` ではなく `map/filter/reduce` を使う
- `function` 宣言ではなくアロー関数を使う
- 不要な抽象化（リポジトリ層、エラーコード enum など）を入れない
- 依存追加は最小限。標準機能で書ける範囲は標準機能で書く

仮説

• LOC、

  any

  数、コメントスタイルはB にかなり近づく
• ただし、規約には書ききれない判断の機微（「Zod を入れるほどの規模ではない」のような抽象的な姿勢）は出にくい

検証は次回の記事に回したい。

考察

ペルソナは「表層」だけでなく「設計判断」にも効いた

事前仮説では「ペルソナは表層スタイルにしか効かず、ライブラリ選定やデータ構造といった設計判断は不変」と考えていた。

しかし実測では

• T3 で全ペルソナが Zod を捨てた── Baseline は迷わず

  zod

  を入れたが、4ペルソナ全員が手書きバリデーションを選んだ
• ファイル分割の深さがペルソナで変わった── D は

  repositories/

  validators/

  routes/

  の4層に分け、B は最小の3層、C は層は浅いが各層が肥大化
• クラス vs 関数モジュールの選択もペルソナ依存── B/D は

  class

  、A は関数モジュール、Baseline と C はその中間

ペルソナは表層スタイルにとどまらず、「依存追加への保守度」「抽象化の重さ」「OOP/関数型の選好」 といった設計判断にも明確に影響する。これは「人格設定はコスメ」だという素朴な想定への反例だ。

「新人」ペルソナの罠 — 仕様外の機能が増える

新人ペルソナはコード量を 約4倍に膨らませるが、肥大化の中身を見ると

• C：

  unhandledRejection

  /

  uncaughtException

  ハンドラを依頼されてないのに追加
• C：

  Context<any, any, any>

  を

  eslint-disable

  付きで導入
• D：T1（一行関数）に template literal type を新設
• D：

  ExitCode

  enum を T2 の CLI に導入
• D：

  PORT

  のレンジチェック（0〜65535）を勝手に実装

つまり「丁寧」「教科書通り」のラベルは、仕様外機能の追加トリガーにもなる。コードレビュー教材として「新人がやりがちなオーバーエンジニアリング」のサンプル生成には使えそう。

「厳格×経験」の組み合わせが最強 — 仮説通り

実用観点で最もコンパクトかつ的確なのは B：シニア×厳格。T1=2行、T2=18行で Baseline よりさらに短い。T3 は 169行 と Baseline（139行）をやや上回るが、これは Baseline が

zod

any

as

「経験」と「厳格」は別の軸 — D ≠ B

同じ「厳格」でも、D（新人×厳格）は B の 約4倍 のコード量になった。差分の正体は

• 経験は「何を書かないか」を知っているが、厳格さは「書ける限り書く」に寄りやすい
• 新人ペルソナは TSDoc のフィールドを全埋めするが、シニアは「書く価値のあるところだけ」書く

「厳格」だけを CLAUDE.md に書くと D 寄り、「シニア」だけ書くと過剰設計回避寄り、両方を組み合わせて初めて B のような締まったコードに到達する。

実用への示唆

実験を通じて見えてきたのは、こういうことだ。

• のは費用対効果が極めて高い。150字程度で LOC が大幅に締まる

  CLAUDE.md

  に「シニア」「厳格」を併記する
• 「新人」ロールは絶対に実装に使わない。教育用サンプル生成に限定する
• 依存追加方針は明示的に書く。「Zod を使ってよい」「標準機能で済む範囲は依存を増やさない」など、ペルソナだけでは制御しきれない
• 層の深さも明示的に書く。「リポジトリ層は作らない」「ハンドラ直書きで OK」など指示しないと、D タイプのペルソナは勝手に層を増やす

実験の限界

• 各パターン×タスクで 1試行のみ。本来は3〜10試行の中央値を取りたい。LLM の揺らぎを考えると、ここで観測した倍率（最大4.6倍）は試行を増やすと変動する可能性がある
• タスクが3つ。特に「アルゴリズム選択が意味を持つ大規模設計タスク」は未検証
• モデルバージョン（Claude Sonnet 4.6）依存。次世代モデルでは挙動が変わり得る
• ペルソナ文に含まれる固有名詞（「TSDoc」「any」など）が出力を直接誘導している可能性があり、「ペルソナ起因」と「キーワード起因」を分離できていない

• tsconfig

  の

  strict

  が有効なので、

  any

  の出現は構造的に抑制されており、より緩い設定では新人系の

  any

  多用が顕著になる可能性

おわりに

「Claude Code に人格を入れると面白いことが起きるのか？」という素朴な疑問から始めた実験だったが、想像以上にコード量・型の使い方・依存選定が変わることが分かった。特に「シニア×厳格」は実用にも十分使える締まり具合で、「新人×フレンドリー」は1試行で Baseline の 4.6倍 までコードが膨らんだ。

ペルソナを書くと 表層スタイルだけでなく設計判断にも影響するという当初仮説への反例も得られた（Zod を捨てた全ペルソナ、層を増やす D など）。

一方で、これは1試行 × Sonnet 4.6 のスナップショットでもある。手元で再現してみると、揺らぎの大きさと、それでも残る「ペルソナの個性」の両方が見えるはず。プロンプトとお題は本記事中にすべて転載しているので、ぜひ試してみてほしい。

参考