この記事の位置づけ
はじめまして、書痴ノートの管理人です。
読書ブログが続きません。
数年前から読書ブログを始めたものの、本は読めども記事にまとめる気力もなく、続かなかった私です（その他プロフィールはこちら）。
そのテコ入れのため、流行りの生成AIさんに相談して続かなかった原因分析をした結果、本記事に至りました。
ということで、この記事は「AI共同開発日誌」シリーズの記念すべき第1回です。
プログラマーではない”ただの会社員”の私が、生成AIツール（ChatGPTやCodexなど）を使用した実用ツール開発を始めた理由を説明する導入記事となります。
はじめに：AI共同開発日誌を始める理由
本シリーズでは、当然具体的な開発手法だったり、手順だったり、コードだったり、技術的な内容も含まれますが、
人間と生成AIの役割分担とそれぞれが担う役割の詳細、会話の内容が中心です。
あくまでも主体は開発・作成したツール自体ではなく、開発に至った経緯や開発中の四苦八苦など、開発過程そのものを記事としてまとめます。
現役開発者向けというよりは、私のような非開発者が生成AIを活用して試行錯誤する過程を記録したものです。
AIは様々なことが出来てしまうからこそ、じゃあなにをさせるのか、なにを作らせるのかを考える・決める力が重要であり、人間が担うものだと感じたため、シリーズとして記事にしようと決めました。
なぜ読書メモツールを作ることにしたのか
冒頭でも書いた通り、本ブログの本懐は書評など読書関連記事ですが継続できませんでした。
ChatGPTと行った原因分析等詳細は長くなるので、次回に書くことにしますが、
結論として、文章力の問題ではありませんでした。
じゃあどうするってことで、まずは公開にこぎつけ、記事数を増やすことを目標に、 読了後最速で公開できるよう、メモレベルでもいいから記事の下書きをさっと作ることができるツール作成を目指しました。
つまり、私に必要だったのは、”完成された記事を書く仕組み”ではなく、”読了直後の情報を確実に残し、抵抗なく記事にする仕組み”でした。
このシリーズの今後
ブログが続かなかった原因分析
読書ブログを続けられなかった原因を、ChatGPTとの対話を通じて整理しました。
思い込みではなく、問題を分解した結果、ツール開発という結論に至るまでの経緯を紹介します。
詳細はこちら（掲載次第リンク
Python CLI版MVPの開発
最初からGUIを作るのではなく、まずは最小限のCLIツールから始めました。
「小さく作って実際に使う」という考え方で進めた理由を紹介します。
詳細はこちら（掲載次第リンク
WordPress運用を前提とした改善
実際に使ってみると、想像していた課題とは違う問題が見えてきました。
運用しながら設計を変えていった過程を紹介します。
詳細はこちら（掲載次第リンク
WordPress REST APIによる下書き自動化
コピー＆ペーストの手間を減らすため、REST APIを利用した下書き投稿にも挑戦しました。
初心者としてどのように学び、実装を進めたのかをまとめます。
詳細はこちら（掲載次第リンク
AIとの共同開発という進め方
ChatGPTとCodexの役割分担や、設計・実装・レビューをどのように進めたかも、実例を交えながら紹介していく予定です。
詳細はこちら（掲載次第リンク
AIがコードを書く時代だからこそ、人間のやることが減ったり奪われているわけではなく、むしろ”何を作るのか”を考え決断する重要性が増しています。本シリーズではその過程も含め記録していきます。
以降、開発そのものと同じように、実際の運用や気付きに応じて内容を見直しながら進めていく予定です。
