Backlogの課題とドキュメントの書式を、Claude CodeのSkillsでそろえる

はじめに

AIインテグレーションユニットの山崎です。

この記事は、BacklogWorld 2026 ブログアドベントカレンダー 7日目の記事です。

前回の記事では、Backlog CLIのbeeをClaude CodeのSkillsとして登録し、ターミナルとブラウザを行き来せずにBacklogの課題やコメントを読み書きする方法を紹介しました。その終わりで、チーム独自の書き方をSkillsに育てる方法にも触れましたが、載せたスキルは簡易的なものでした。

今回はその続きとして、私がrevsystem/claude-code-skillsで公開しているBacklog用のスキルのうち、課題を作るbacklog-create-issueと、ドキュメントを作るbacklog-create-documentを紹介します。同じスキルをチームで使えば、誰が依頼しても、課題とドキュメントの見出しと用語が揃います。新入社員の受け入れ準備を題材に、Claude Codeとの会話から課題とドキュメントが完成するまでを、実際の画面で追っていきます。

なお、今回紹介する2つのスキルは、私が個人で公開しているものです。

BacklogWorld 2026 ブログアドベントカレンダー 2日目の記事では、Backlog MCPサーバーとClaudeデスクトップを組み合わせた事例がAIにBacklogの課題を作ってもらうようになって、仕事がどう変わったかとして紹介されています。こちらもあわせてご覧ください。

課題の書き方は、人によって違う

チームでBacklogを使っていて、次のようなことで困ったことはないでしょうか。

課題の書式や粒度が人によって違い、必要な情報が抜けていたり、逆に細かすぎて必要な情報が探しにくかったりする。課題のテンプレートを用意しても、手で入力する手間が障壁になり、いつの間にか使われなくなる。

書式をそろえる仕組みを、人の注意力に頼らずに回す方法のひとつが、書き方そのものをスキルに書いておくことです。Claude Codeは課題を作るたびにスキルを読み込み、同じ見出しと語彙を使って本文を組み立てます。依頼する人は、何を作りたいかを会話で伝えるだけで済みます。

会話から、課題とドキュメントができるまで

題材は、新入社員の受け入れ準備

ここからは、カスタマーサービス部に11 月 1 日付で新入社員が1名入社するという架空のストーリーで説明します。部署のリーダーとして受け入れ準備を進めるため、Claude Codeに相談しながら、Backlogのサンプルプロジェクト（SAMPLE）に課題とドキュメントを作成します。

やりとりを重ねて、前提を固める

最初の依頼は次の1文です。

来月 1 日に、カスタマーサービス部に新入社員が 1 名入社します。受け入れ準備を始めたいので、相談に乗ってください。

Claude Codeは、11 月 1 日が日曜日であることを指摘し、初出社日、PCやアカウントの手配先、担当窓口、メンター、一人で対応を始めるまでの期間について質問しました。私の回答は次のとおりです。

初出社日は 11 月 4 日（水）です。11 月 3 日が祝日のため、11 月 2 日に休暇を取得しているメンバーが多いため4日を初出社日にしてもらいました。PCやアカウントの手配は、情報システム部に依頼済みで、4日の10時までに新入社員の机に配布されます。新入社員は主にチャットの窓口を担当します。メンターは同じ部署のリーダー川口さんが担当します。最初の11 月中は、人事部が担当する研修と、カスタマーサービス部の研修の予定が組まれています。

Claude Codeは、決まったことを表に整理したうえで、部署固有のツールのアカウントを誰が用意するか、初日の朝の過ごし方、研修の分担を質問しました。2回目の回答の後、まだ決まっていないこと（部内研修の担当者とゴール、2つの研修日程を誰が突き合わせるか）と、依存関係（パスキーの登録にはPCが要る）を挙げ、作業を3つに分ける案を示しました。

課題を作る

「課題を作ってください」と依頼すると、Claude Codeはbacklog-create-issueの手順に沿って、プロジェクトの記法（Markdown）と課題種別を確認し、親課題1件と子課題3件のドラフトを提示しました。

作成直後の親課題（SAMPLE-1）の画面は次のとおりです。ドキュメントを作ると、Referencesに成果物:の行が後から加わります。

親課題 SAMPLE-1（作成直後）

作成した課題には、スキルのルールが次のように反映されています。

• Target environmentは省略されました。複数の環境（テスト環境や本番環境）へ順に展開する課題ではないためです
• Out of scopeは、誤解されやすい範囲（情報システム部に依頼済みのPCの手配、人事部が組む研修）がある親課題にだけ置かれました
• 各課題のTodo Listの最後に、何を見て完了とするかの項目が入りました
• 会話で決まらなかった事柄は推測で埋められず、「決める」作業としてTodoに置かれました

ドラフトの子課題には、日付に関わる次の記述がありました。

このドラフトに対して、私は開始日と期限日を以下のように指定しました。

子課題の開始日は11/4にしてください。子課題1の期限を11/4、2の期限を11/6、3の期限を11/10にしてください。必然的に親課題の開始日は11/4、期限は11/10となります。

Claude Codeは作成する前に、指定した日付とドラフトの記述が食い違う箇所を2つ指摘しました。

• 初日の受け入れ準備：開始日の11 月 4 日より前に、11 月 2 日までに済ませる確認項目がある
• 研修日程の全体調整：着手条件は子課題2（期限11 月 6 日）の完了後なのに、開始日が11 月 4 日になっている

それぞれ2つの修正案が示されたので、初日の受け入れ準備の開始日を11 月 2 日に早める案と、全体調整の着手条件を「部内研修の日程案がそろい次第」に変更する案を選びました。作成した課題の日付は次のとおりです。

子課題（SAMPLE-2）の画面は次のとおりです。

子課題 SAMPLE-2

ドキュメントを作る

続けて「受け入れの方針と初日の流れをドキュメントに整理して」と依頼しました。Claude Codeはbacklog-create-documentの手順に沿って、方針をSAMPLE-1の成果物、初日の流れをSAMPLE-2の成果物として、2つのドキュメントに分けました。初日の流れは、方針の子ページとしてツリーに配置しています。

SAMPLE-1 の成果物「新入社員の受け入れ方針」

方針のドキュメントは、ヘッダの課題:で元の課題を示し、続く2文で範囲を書いています。本文の見出しは「初出社日をいつにするか」「誰が何を用意するか」のように、読者の問いかけの形です。

SAMPLE-2 の成果物「新入社員の初日の流れ」

初日の流れを書く途中で、Claude Codeは日程の食い違いを見つけました。初日の10時以降の予定は、研修日程が確定しないと決まりません。ところが前述の表のとおり、初日は11 月 4 日で、研修日程を確定するSAMPLE-4の期限は11 月 10 日です。このままでは、初日の予定が初日までに決まりません。Claude Codeはこの予定を推測で埋めずに未決事項としてドラフトに残し、どう扱うかを確認してきました。そこで、SAMPLE-2のTodoに「11 月 2 日までに、PCが届いた後の初日の予定を、研修日程の確定（SAMPLE-4）を待たずに決める」を足すよう依頼してから、ドキュメントを作成しました。

作成後は、元の課題のReferencesに成果物:の行を追記します。ここで1つ制約があります。BacklogのDocument APIには作成済みドキュメントを更新する手段がないため、先に作成した方針のドキュメントから、後で作成した初日の流れへのリンクは張れません。今回はツリーの親子関係でたどれるようにしました。

やりとりを重ねずに、1文で依頼すると

比較として、Claude Codeとのやりとりを重ねず、1文で依頼した場合も試しました。

12 月 1 日にカスタマーサービス部へもう 1 名入社するので、受け入れ準備の課題を作って。

作成された課題（SAMPLE-5）の画面は次のとおりです。

1文の依頼で作成した SAMPLE-5

前述のSAMPLE-1と比較すると、次のようになります。

見出し、完了確認の書き方、Referencesの語彙は揃っており、違いは中身に出ました。SAMPLE-5のReferencesは、前例としてSAMPLE-1と方針のドキュメントを指しています。

スキルには、何を書いているか

ここまでの課題とドキュメントの形は、2つのスキルに書いた決まりから来ています。書式と用語をそろえるために効いている決まりを3つ挙げます。

見出しの名前と数を固定する

backlog-create-issueは、課題本文の見出しを次の5つに固定し、「この5つ以外の見出しを増やさない」と明記しています。必須はOverview / Todo List / Referencesの3つで、Target environmentとOut of scopeは条件を満たすときだけ足します。「前提条件」や「注意点」の見出しを立てたくなる内容は、Overviewにまとめて書きます。

Todo Listは完了条件を兼ねます。そのため「作業した」で終わらせず、何を見て完了と判断するかの項目を必ず1つ以上入れます。親子課題は、別々に進めて別々に完了を確かめられる作業ごとに分け、親課題には全体像を、子課題には親課題のキーと前の作業の成果を書きます。

backlog-create-documentも同じ考え方で、ドキュメントの項目とその順番を固定しています。ヘッダ（元の課題や前提の資料へのリンク）、範囲（この文書が定めることと扱わないもの）、本文の節（読者の問い1つに1節で、節の1文目にその節の結論）、未決事項（決まっていないことと、決める時期・担当）の順です。範囲の文と各節の1文目が結論を兼ねるので、本文を言い換えた「まとめ」の節は置きません。

役割ラベルの付け方を決める

課題のReferencesとドキュメントのヘッダは、1行に1種類の参照を置き、行頭に役割ラベルを付けます。ドキュメントのヘッダは課題: 前提: 手順: 関連: 別紙:の5つに決め、それぞれの意味と省略できる条件を表にまとめています。課題のReferencesはParent: 前提: 設計: 成果物: 議論:を例として示し、参照先の役割に合わせて題材:や前作:のようなラベルを付けられます。固定しているのはラベルの一覧ではなく「行頭にその参照の役割を書く」という形で、「参考」「関連資料」「リンク」のように役割の分からない呼び名が混ざるのを防ぎます。

チームの決まりを優先し、作る前に見せる

記法（MarkdownかBacklog記法か）は、作成のたびにbee project view -p <PROJECT> --json textFormattingRuleで確かめ、記憶に頼りません。言語は、親課題や同じ流れの直近の課題に合わせます。プロジェクト側に課題のテンプレートが定義されていれば、スキルのテンプレートよりそちらを優先します。チームがすでに決めている書式とぶつからないようにするためです。

課題もドキュメントも、作成前にドラフトを提示して承認を得る手順にしています。他のメンバーが読む記録なので、無断では作りません。先ほどの例で、日付の食い違いや初日の予定の抜けに作成前に気づけたのは、この手順があるからです。

はじめ方

2つのスキルは、課題とドキュメントの作成にbeeを使います。beeのインストールと認証、beeが配布するスキル（using-beeとbacklog-notation）の登録は、前回の記事の「はじめ方」を参照してください。

beeが使える状態になったら、2つのスキルをスキル名を指定して1つずつインストールします。

gh skill install revsystem/claude-code-skills backlog-create-issue --agent claude-code --scope user
gh skill install revsystem/claude-code-skills backlog-create-document --agent claude-code --scope user

この記事の例は、Claude Code 2.1.314とbee 1.1.1で、記法設定がMarkdownのBacklogプロジェクトに対して動かしたものです。

まとめ

backlog-create-issueとbacklog-create-documentを使い、会話からBacklogの課題とドキュメントを作るまでを紹介しました。見出しの名前と数、役割ラベルの付け方、完了条件の書き方をスキルで固定しておくと、依頼の仕方が違っても、できあがる課題とドキュメントの形はそろいます。

また、スキルの手順に沿って書く過程で、日付と本文の食い違いや、研修日程と初日の予定の依存関係が見つかりました。決まっていないことを推測で埋めず、「決める」作業や未決事項として残す決まりがあるため、抜けていた段取りにも作成前に気づけました。

みなさんのチームで使う場合は、スキルを自分たちの書式と用語に合わせて書き換えてください。書式と用語がそろえば、どの課題やドキュメントでも同じ場所に同じ種類の情報が並びます。探す手間が減り、チームで情報を整理して共有しやすくなります。

参考情報

• Backlogと開発ツールを行き来する疲れを、bee × Claude Codeでなくす（前回の記事）
• revsystem/claude-code-skills (GitHub)
• bee (GitHub)
• bee ドキュメントサイト