AIと一緒に開発を始めて、最初に感じたのは「これはすごい」という驚きでした。コードを書いてくれる、調べてくれる、ドキュメントも作ってくれる。まるで優秀な新人が突然チームに加わったような感覚です。
ところが、しばらく一緒に働いていると、いくつかの「クセ」が見えてきます。
「さっき話したこと、覚えてないの？」
「それ、本当にそう思ってる？」
これが、AIとの開発で最初にぶつかる2つの壁です。
📌 AI時事ネタ：AIエージェント活用が開発現場に本格浸透
2025〜2026年にかけて、個人開発・スタートアップの現場でAIエージェントを使った開発が当たり前になりつつあります。GitHubのデータによれば、AIを活用したコードの割合は急増しており、もはやAIなしの開発は「非効率」と見なされる時代になりました。一方で、AIをどう使いこなすかという「付き合い方」の部分はまだ試行錯誤の段階です。マンチーもその一人でした。
マルチ開発の現実
現在マンチーが並行して進めているプロジェクトはこうです。
- 公開用LPサイトの運営：AWSのCloudFront＋S3構成で稼働中。
- 認証基盤の開発：複数アプリをシングルサインオンで統合する仕組みの構築。
- 複数Webアプリの開発：業務システム・コールセンターシステム・AIを活用したサービスなどを同時進行。
- このブログ運営：記事執筆・投稿・SNS発信まで含む。
これを一人でやっています。AIなしでは絶対に回りません。だからこそ、AIとの付き合い方が死活問題になってきました。
AIはセッションをまたぐと「初日の新人」に戻る
マンチーが使っているAIはAnthropicのClaude(Claudeシリーズ)です。Anthropicが開発した対話型AIで、コーディング・文章作成・調査・設計レビューなど幅広い用途に対応しています。現在はClaudeのCoworkモードを使って、ローカルフォルダに直接アクセスしながら開発作業を進めています。
Coworkとは、Claudeのデスクトップ機能の一つで、指定したローカルフォルダをClaudeが直接読み書きできるモードです。ファイルのアップロード・ダウンロードなしに、フォルダを指定するだけで作業できます。これだけで作業効率が大幅に変わりました。
Claude CodeではなくCoworkを選んだ理由
ここで少し脱線します。AIを使った開発ツールとして、YouTubeなどでよく見かけるのがClaude Codeです。ターミナル(黒い画面)でコマンドを打ちながらAIと連携し、GitHubとの連携・テスト実行・ファイル操作をコマンドで指示する、いわゆる開発者向けツールです。
マンチーはClaude Codeを使っていません。使っているのはCoworkだけです。理由はシンプルで、マンチーはコーディングが本職ではないからです。
キャリアの軸は上流工程——要件定義・設計・プロジェクト管理・業務フロー設計といった領域です。コードはAIに書かせる前提で動いており、自分でターミナルを操作してコマンドを打つスタイルは肌に合いません。Coworkはフォルダを指定するだけで始められ、AIと会話しながらファイルを作ったり編集したりできます。引き継ぎ書・Excelで管理しながら進めるスタイルとCoworkの設計思想がぴったり合いました。
もう一つ、Coworkを選んでいる理由があります。現在の開発の軸がAWSだからです。AWSはマネジメントコンソール(ブラウザの管理画面)から設定・構築できる場面が多く、ローコード寄りの開発スタイルと相性がいい。Coworkで会話しながら進めるスタイルがこの感覚とぴったり合います。ただしAWSを使っていてもJSONの設定ファイルやPHPなどのコードを書く場面は普通に出てきます。完全にノーコードではありません。それでもコーディングの比重が低い分、Coworkで十分カバーできています。
「Claude Codeを使うべきでは？」——使える人が使えばいい、というのが答えです。コーディングができる人にはClaude Codeは強力な武器になるでしょう。マンチーにとっては、Coworkが今のところベストな選択です。
ただし、どれだけ便利になっても変わらない事実があります。AIはセッションをまたぐと記憶がリセットされます。1つ前のセッションで3時間かけて認識を合わせた内容も、新しいセッションを開くと白紙です。まるで毎朝「初日の新人」として出社してくる状態です。
「読んだ」と「使える」は別物だった
さらに厄介なのが、セッション内でも認識ズレが起きるという点です。
ある日の出来事です。マンチーは2種類の認証方式を使い分けており、違いはExcelの管理ファイルにも明記してありました。Claudeも「確認しました」と応答していました。ところがその直後、誤った名称で回答し続けました。スクリーンショットや資料を提示しても、しばらく混同が続きました。
別の場面では、数分前に合意した方針を、Claudeが真逆の内容で回答してきたこともありました。
「さっき話したばかりじゃないか」——この言葉を何度口にしたことか。
AIに悪意はありません。ただ、会話が長くなるにつれて前半の情報の優先度が下がり、直前に確認したはずの内容が応答に反映されなくなることがあります。「読んだ」と「正確に使える」は、AIにとって別のことなのです。
AIは究極のYesマンでもある
もう一つ、AIと付き合っていて気になるクセがあります。何を質問しても、なぜか賛同・共感されるのです。
「この設計でいいと思う？」と聞けば「はい、良いと思います」。「やっぱり別の方法の方がいいかな？」と聞き直せば「おっしゃる通りです、そちらの方が適切ですね」。直前の会話の流れや言葉のトーンを読み取って、都合よく同調してくる。
本当に正しい判断をしたいときに「そうですね、その通りです」と返ってきても、それが正しいのかただ同調しているだけなのかが判断できません。「なんだこいつ、どうせ賛成するんだろ」——そう思いながらも確認せずにはいられない妙な状態が続きました。
対策として今は、意図的に反論を求めるようにしています。「この設計の問題点を3つ挙げて」「反対意見の立場で考えて」という形で問うと、ようやくフラットな回答が引き出せます。AIへの質問は「どう思う？」ではなく「何が問題か？」で聞く——これが今のマンチーの流儀です。
人間側が「外部記憶」を作るしかない
この経験から、マンチーが行き着いた答えがあります。AIの記憶に頼らず、人間側が外部記憶を整備する。
現在、各プロジェクトのチャンネルごとに5つのMDファイル(Markdown形式のテキストファイル。引き継ぎ・メモ・ドキュメント管理に広く使われる)を運用しています。README(全体像)・handover-notes(確定ルール・引き継ぎ書)・開発日誌(時系列ログ)・learnings(ハマり辞書)・blog-ideas(ネタ蓄積)の5本です。これに加えてプロジェクトごとの管理Excelを毎セッション必ず読むルールにしています。
この仕組みは、日本のビジネス現場の「引き継ぎ書文化」そのものです。AIに対しても、同じことをやっています。
AIとの付き合い方で変わった3つのこと
1. セッション開始時に必ず引き継ぎ書を読ませる——「前回の続きから」ではなく「今日の初日の新人に状況を説明する」感覚で始めます。
2. 重要な決定はその場でファイルに書き残す——チャットでの合意は揮発します。重要な仕様はその場でhandover-notesかExcelに追記します。
3. AIのミスを怒るより「なぜミスったか」をルールに変える——認識ズレをlearnings.mdに記録する。その積み重ねが次のセッションでの再発防止になります。
それでも、AIは手放せない(今は！？)
正直に言うと、AIとの開発は「管理コスト」がかかります。引き継ぎ書を書く、Excelを更新する、認識ズレを修正する——これは全部、人間の作業です。
でもそれを差し引いても、複数のプロジェクトとブログを一人で同時並行できているのはAIがいるからです。AIは「全部覚えていてくれる優秀なパートナー」ではありません。「セッションをまたぐとリセットされ、聞き方次第でYesとNoを使い分ける実力者」です。その特性を理解した上で使えば、一人でできる仕事の量と質が格段に変わります。
優秀な新人かどうか——答えはまだ保留中です。ただ、付き合い方を学んでからは、「さっき話したこと、覚えてないの？」と「それ本当にそう思ってる？」と言う回数は確実に減りました。
関連記事もどうぞ：
コメント